Other pages in this section Permissions and Data Clusters for AIS journeys Account Information Consent Refreshing AISP access Consent Dashboard & Revocation AIS Access Dashboard & Revocation Access Status notifications by ASPSPs AIS Access for PSUs from Corporate Entities
This content is best viewed on a desktop browser. 1 CX Considerations 1AISP 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. 2 CEG Checklist Requirements 2AISPs 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 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. The functions “cancel assess” and “back” should be displayed with equal prominence to the PSU. “Agent” means a person or entity who acts on behalf of an authorised payment institution or a small payment institution in the provision of payment services including account information services. 3 CX Considerations 3The AISP should make the exact consequences of cancelling the consent clear to the PSU – i.e. they will no longer be able to provide the specific service to the PSU 4 CX Considerations 3The AISP should make the exact consequences of cancelling the consent clear to the PSU – i.e. they will no longer be able to provide the specific service to the PSU 5 CEG Checklist Requirements 4AISPs 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 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 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). Select to scroll left Select to scroll right
CEG Checklist Requirements & CX Considerations 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. 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 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. The functions “cancel assess” and “back” should be displayed with equal prominence to the PSU. “Agent” means a person or entity who acts on behalf of an authorised payment institution or a small payment institution in the provision of payment services including account information services. 13b 3 The AISP should make the exact consequences of cancelling the consent clear to the PSU – i.e. they will no longer be able to provide the specific service to the PSU 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 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 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). 9
Refreshing AISP access Previous Related articles Please select API specifications Consent Revocation Changes to an Intent's Authorized State DELETE account-access-consents AIS Access Dashboard & Revocation Next