Change Log

Detailed list of changes from V1.3 to V3.1.3 (no interim versions published)

Changes are indicated as follows. Copy which has been removed is struck out and copy which has been added is in blue.

ItemSection ReferenceDescription of ChangeReason for Change
Section Authentication methods
1Authentication methods 5. No Obstacles: ASPSPs must not create unnecessary delay or friction during authentication including unnecessary or superfluous steps, attributes, or unclear language, e.g. advertising of ASPSP products or services,  language that could discourage the use of TPP services or additional features that may divert the PSU from the authentication process.

Additional clarification
Section Account Information Services (AIS)
2Account Information Services
  • Access Dashboard and Revocation - ASPSP facility to enable a PSU to view all AISPs that have access to their account(s) and the ability to revoke that access. This must be available on all channels that a PSU could access via the ASPSP directly and be easy and intuitive for PSUs to find and use. This facility should not include unnecessary steps, superfluous information or language which could discourage the use of TPP services or divert the PSU from the access management process.
Additional clarification
3Account Information ConsentIn this journey the AISP presents to the PSU a description of the data that it requires in order to support its service proposition.
PSU selects the ASPSP(s) where their payment account(s) is held. The PSU is then directed to the domain of its ASPSP for authentication and to select the account(s) they want to give access to. Once the PSU has been authenticated, their ASPSP will be able to respond to the AISP's request by providing the account information that has been requested.

When considering AISP requests submitted by a PSU acting with delegated user authority on behalf of a corporate entity, the PSU may only be able to use AISP services, if this is permitted within the parameters of that delegated user authority. If the PSU does not have the appropriate delegated user authority, please refer to journey AIS Access for PSUs from Corporate Entities		Typos
4Account Information Consentitem #2
AISPs must provide PSUs with sufficient information to enable PSUs to make an informed decision, for example, detail the purpose for which the data will be used (including whether any other parties will have access to the information) the period over which it has been requested and when the consent for the account information will expire (consent could be on-going or one-off).
If the customer-facing entity is acting on behalf of an AISP as its agent, the PSU must be made aware that the agent is acting on behalf of the AISP.

item #4
If the customer-facing entity is acting on behalf of an AISP as its agent the ASPSP should make the PSU should be made aware that the agent is acting on behalf of the AISP.		Typos and clarification
5Account Information ConsentChanges to the wireframe.Clarification 
6Consent Dashboard & Revocationitem #2
AISPs must describe the data being shared through each consent using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language below) and ensure this request is specific to the only the information required for the provision of their account information service to the PSU.
AISPs should present the data at a Data Cluster level and allow the PSU to expand the level of detail to show each Data Permission.
The Consent Dashboard should also describe:
  • The purpose of the data request (including whether any other parties will have access to the information). Where the request is for multiple product types, the detail should explain to the customer the product type to which it applies or state that it is shared across multiple product types.

  • If relevant, the length of time for which this consent is valid (e.g. one off use, for a set period of time e.g. one year, or with no end date).

  • The period for which the transaction data has been requested (e.g. transactions for the last 12 months).

  • When the TPP's access to the data will expire.

  • The date the consent was granted.

If the customer-facing entity is acting on behalf of an AISP as its agent, the PSU must be made aware that the agent is acting on behalf of the AISP.
The consent dashboard must allow a PSU to view or cancel the access they have given consent to. These functions “cancel access” and “back"should be displayed with equal prominence to the PSU.

item #4
AISPs must inform the ASPSP that the PSU has withdrawn consent by making a call to DELETE the account-access-consent resource as soon as practically possible (as described in Release Version 3 of the API specifications). This will ensure that no further account information is shared.

ASPSPs must support the Delete process as described in the Release Version 3 API specifications. (This is not visible to the PSU but will ensure no further account information is provided by the ASPSP to the AISP).

item #1
AISP should offer functionality ( e.g. search, sort, filter) to enable a PSU to search for the relevant consent. This will be of particular benefit as the number of consents for different ASPSPs/ accounts given by a PSU to TPPs increases.		Clarification and backlog 
7AIS Access Dashboard RevocationChanges to the wireframe.Clarification
8AIS Access Dashboard Revocationitem #3
ASPSPs must describe the data being accessed using the structure and language recommended by OBIE following customer research (see Data Cluster Structure & Language below).

ASPSPs should present the data at a Data Cluster level and allow the PSU to expand the level of detail to show each Data Permission.

The Access Dashboard should also describe:
  • The status of the authorisation access e.g. Active or Inactive.

  • When the AISP's access to the account(s) will expire.

  • The date the authorisation was granted.
And may include date of last access.

item #5
The access dashboard must allow a PSU to view or cancel the access they have given consent to. These 2 functions functions “cancel access” and “back” should be given equal prominence when offered to the PSU.

ASPSPs must advise PSUs that they should contact the associated AISP to inform them of the cancellation of access and/or understand the consequences of doing so.

item #2
ASPSPs should offer a functionality ( e.g. search, sort, filter) to enable a PSU to search for the relevant access. This will be of particular benefit as the number of consents given by a PSU to TPPs increases.

item #3
ASPSPs should advise PSUs that they should contact the associated AISP to inform them of the cancellation of access and/or understand the consequences of doing so.

item #4
ASPSPs should make the status of TPP access clear by the use of emboldened words. The ASPSP should also make it clear, which party provided the AISP access, in the case of joint/ multiple account holders.		Clarification and backlog
9AIS Access Status Notifications by ASPSPMandatory notification mechanisms between AISPs and ASPSPs:
C. Real Time Notification from AISP to ASPSP on revocation of consent

This functionality enables the AISP to notify the ASPSP in real time (i.e. immediately) after the PSU revokes their consent at their AISP consent dashboard, provided that the AISP takes immediate action upon the PSU revocation. The current Open Banking V3 Read/Write specifications enable an AISP to use the 'DELETE' API endpoint and notify the ASPSP that the PSU has revoked their consent.

The implementation of the ‘DELETE’ API endpoint is mandatory for ASPSPs.

Note: For AISPs, when the PSU revokes their consent at the consent dashboard, AISPs must not call any protected data resource which falls within the scope of the consent originally granted. This AISP must delete the account-access-consent resource with the ASPSP notify the ASPSP "immediately", by using the ‘DELETE’ end point as soon as practically possible. From a technical perspective, if the AISP fails to use the ‘DELETE’ endpoint and accordingly the ASPSP does not receive the notification, the AISP would still be able to access the PSU's account for the remaining duration of their access token (notwithstanding any SCA requirements). We note that failure of deletion and subsequent use of the access consent could have implications under both GDPR and PSRs. As, such, we would expect AISPs to have robust controls in place to ensure that the use of the ‘DELETE’ endpoint occurs seamlessly upon revocation of the consent at their dashboard by the PSU and that no further access to the account takes place. AISPs wishing to regain access to the PSU's account, must agree new consent parameters with the PSU.		Clarification
10Permissions and Data Clusters for AIS journeysPermission Language
Any other name by which you refer to this account, and/or the currency of the account.		Clarification
11Permissions and Data Clusters for AIS journeysContact and party detailsPartyPartyPSUThe name of the account and your full legal name.
Optionally this can also include your address, telephone numbers and email address as held by the bank/card issuer*		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.).Clarification
Account specific:
Parties		PartyThe full legal name(s) of account holder(s).
Address(es), telephone number(s) and email address(es)* 		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.).
* Include or delete as appropriate
12Single Domestic Payments - a/c selection @ PISP (Supplementary info)ASPSPs should inform PSUs about their “point of no return” for making the payment and that their payment will be made after pressing the Proceed button. Example wording: “Press Proceed to make payment“

In principle, while the PSU has the ability to cancel an authentication journey the expectation is for the ASPSP to redirect the PSU to the domain of the TPP and send the appropriate error code and description to the TPP, as supported by the OIDC Redirect Model.		New change to reflect and additional clarification to CX
13Single Domestic Payments – a/c selection @ ASPSPSee changes to wireframe New change to reflect FCA High-Cost Credit Review.
14Single Domestic Payments – a/c selection @ ASPSPAdditional Parameters
ASPSPs must allow PSUs to select the payment account to complete the payment order for execution.

ASPSPs must ensure that they comply with their obligations relating to the FCA’s High Cost Credit Review: Overdrafts consultation paper and policy statement (CP18/42).		New change to reflect FCA High-Cost Credit Review.
Section Card Based Payment Instrument Issuers (CBPIIs)s
15CBPII Access Dashboard & RevocationChange to wireframe.Clarification/ backlog
16CBPII Access Dashboard & Revocationitem #3
ASPSPS must  allow PSUs to revoke the CoF access for each CBPII to a specific PSU account.

ASPSPs must advise PSUs that they should contact the associated CBPII to their payment account to inform them of cancellation of CoF access to their account and/ or to fully understand the potential implications of doing so.

item #4
Revocation Request

ASPSPs must allow PSUs to confirm that they want to revoke CoF access of their account to a specific CBPII.

ASPSPs should inform PSUs that once CoF access is revoked, the CBPII will no longer be able to check the availability of funds in their account. This may cause their CBPII transactions to be declined.

ASPSPs whose access have been revoked should inform them of them of the cancellation of CoF access to their account and/or fully understand the potential implications of doing so.

ASPSPs must advise PSUs that they should contact the associated CBPII to their payment account to inform them of cancellation of CoF access to their account and/ or to fully understand the potential implications of doing so.

ASPSPs must should give equal prominence to the choices of continuing or cancelling the CBPII CoF access.		Clarification
17CBPII Revocation of ConsentCBPIIs must inform ASPSPs that PSUs have withdrawn their consent by making call to the DELETE API endpoint as soon as practically possible (as described in Release Version 3 of the Read/Write API specifications). This will ensure that no further CoF account access will be accepted by ASPSPs.

Note 1: ASPSPs must support the Delete process as described in the Release Version 3 Read/Write API specifications.

Note 2: This activity is not visible to PSUs as it takes place in the background, however it will ensure no further CoF responses are provided by ASPSPs to CBPIIs).		Clarification
Section The Customer Experience Checklist
18Explanation of the Customer Experience Guidelines ChecklistCustomer-Experience-Guidelines-Checklist-v3.1.3-Final.xlsx

Checklist now called 3.1.3
v3-1-3