Version

Date

Description of Changes

Bahrain OBF v1.0.0

25th Aug 2020

Initial Release

S.No.

Customer Experience Checklist and Customer Experience

Considerations 

 Participant

Implementation Requirements

1

Consent Selection

AISP must allow

users/

customers to select the relevant consent for revocation.
AISPs must display the company’s trading name/brand name (i.e. the Client Name) to the user/customer during the setup and revocation of consent. If the AISP is only trading with its registered company name then it must display that name to

the

user

/

customer

.

CX consideration:

AISP should provide

users/

customers with multiple selection options to manage/revocate consent.
AISP should offer functionality (e.g. search, sort, filter) to enable a user/customer to search for the relevant consent. This will be of particular benefit as the number of consents for different ASPSPs/ accounts given by a user/customer to AISPs increases.

AISP

Required

2

Consent Details

AISPs must describe the data being shared through each selected consent using the structure and language recommended by

Bahrain OBF.

The Consent must also describe:

• A description of the account information service that is being provided

• 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

• The date when consent was first granted

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

CX consideration:

AISPs should present the data at a Data Cluster level and allow the user/customer to expand the level of detail to show each Data Permission.

AISP

Required

3

Information Display

The AISP must make the exact consequences of cancelling the consent clear to the user/customer – i.e. they will no longer be able to provide the specific service to the user/customer.

AISP

Required

4

Cancel the permission

The consent dashboard must allow a user/customer to cancel the access they have given consent to. The functions “Cancel Permission” and “back” must be displayed with equal prominence to the user/customer.
Once the user/customer confirms revocation, AISPs must inform the ASPSP

that the user/customer has withdrawn consent by making a call ‘to PATCH’ the account-access-consent resource as soon as practically possible. This will ensure that no further account information is shared.
ASPSPs must support the revocation process. (This is not visible to the user/customer but will ensure no further account information is provided by the ASPSP

to the AISP).

AISP

Required

5

AISP Confirmation

AISPs must provide a message to consumers that revocation was successful. This message to be clearly visible on the dashboard and shown as soon as revocation has taken place.

CX consideration:

After the Patch endpoint is called by the AISP to remove the account-access-consent resource, the ASPSPs are advised to inform the user/customer via their own channels (for example via SMS or via a notification on their mobile phone) that the AISP will no longer have access to their account. This is an additional confirmation to the user/customer that the AISP has completed the revocation process correctly.

AISP

Required

6

Post Customer revocation, AISPs must delete the entire customer data from their storage system.

AISP

Required

S.No.

Customer Experience Checklist and Customer Experience

Considerations 

 Participant

Implementation Requirements

1

 Notification by AISP

AISPs must alert the user/customer when authentication needs to be performed to re-authenticate AISP access.

CX consideration:

• AISPs should make it clear that the user/customer is being asked to authenticate to extend the AISP access to their account data and that no other element of the consent (e.g. the data permissions required, the purpose for which it will be used etc.) will change

AISP

Required

2

Consent Selection

• AISP must allow user/customer to select the relevant consents for re-authentication

• The customer-facing entity must provide users/customers with sufficient information to enable them 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

• AISPs must display the company’s trading name/brand name (i.e. the Client Name) to the user/customer. If the AISP is only trading with its registered company name then it must display

• that

• name

• to

• the user/customer

CX consideration:

• AISP should provide user/customer with multiple selection options to manage/re-authenticate consent

• AISP should offer functionality (e.g. search, sort, filter) to enable a user/customer to search for the relevant consent. This will be of particular benefit as the number of consents for different ASPSPs/ accounts given by a user/customer to AISPs increases

AISP

Required

3

Consent Details

AISPs must describe the data being shared through each selected consent using the structure and language recommended by

Bahrain OBF.

CX consideration:

• AISPs should present the data at a Data Cluster level and allow the user/customer to expand the level of detail to show each Data Permission

• Generic AISP to ASPSP

• redirection screen and message

AISP

Required

4

SCA - Strong Customer Authentication

• ASPSP

• must allow users/customers to perform a SCA Authentication. The ASPSP

• authentication must have no more than the number of steps that the user/customer would experience when directly accessing the ASPSP

• channel

• ASPSPs must not replay the data requested (as a default) or seek re-confirmation of consent

• ASPSPs must display the AISPs’ trading name/brand name (i.e. the Client Name in the software statement) to the user/customer during authentication screens and on any Access Dashboards

CX consideration:

• If the ASPSP

• provides an option for the user/customer to view the data they have consented to share with the AISP as supplementary information, this must be done using the structure and language recommended by

• Bahrain OBF (see Data Cluster Structure & Language below). Display of such information must not be provided to the user/customer as a default

• Generic ASPSP

• to AISP redirection screen and message

ASPSP

Required

5

AISP Confirmation

AISPs must confirm the successful completion of the consent re-authentication to the user/customer.

AISP

Required

S.No.

Customer Experience Checklist and Customer Experience

Considerations 

 Participant

Implementation Requirements

1

User Selection

ASPSPs must allow

users/

customers to view a list of connected AISP service providers and allow

users/

customers to select the AISP for access revocation.
ASPSPs must display the AISPs trading name/brand name (i.e. the Client Name in the software statement) to the user/customer on any Access Dashboards. They do not need to display the registered company name of the AISP even if it is different

.

CX consideration:

• ASPSPs should provide user/customer with multiple selection options to manage/

• revocate access

• ASPSPs should offer a functionality (e.g. search, sort, filter) to enable a user/customer to search for the relevant access

 ASPSP

 Required

2

ASPSP Information Display

ASPSPs must describe the data being accessed for the selected AISP using the structure and language recommended by

Bahrain OBF. ASPSPs should present the data at a Data Cluster level and allow the user/customer to expand the level of detail to show each Data Permission.

ASPSPs must make available on all digital channels an access dashboard

that allows

users/customers to view access which has been previously granted and it must be easy and intuitive for

users/customers to find and use.

The Access Dashboard

must also describe:

• The status of the access e.g. Active/Inactive

• When the AISP’s access to the account(s) will expire, if available

• The date the authorisation was granted

• And may include the date of last access

ASPSP

Required

3

ASPSPs must advise

users/customers that they should contact the associated AISP to inform them of the cancellation of access and/or understand the consequences of doing so before the user/customer confirms the revocation of access.

ASPSP

Required

4

The access dashboard must allow a user/customer to view or cancel the access they have given consent to. These functions “cancel access” and “back” should be given equal prominence.

 ASPSP

Required

5

ASPSPs must inform the user/customer via their own channels (for example via SMS or via a notification on their mobile phone or via in screen messages) that AISP will no longer have access to their account.

ASPSP

Required