1. Version Control

Version	Date	Description of Changes
Bahrain OBF v1.0.0	28^th Oct 2020	Initial Release

2. Introduction

The Customer Experience Guidelines form a part of the Open Banking Implementation requirements and set out the customer experience required to deliver a successful Open Banking Ecosystem, alongside technical, performance and dispute resolution practices.

The Customer Experience Guidelines have been developed with the following key considerations:

The user’s/customer’s experience and the interplay between Third Party Platforms, including but not restricted to AISP, PISP, and ASPSP is as seamless as possible
Information is presented in an intuitive manner that is easy to comprehend and allows the customer to make informed decisions
Sufficient measures are taken to gain customer trust through a secure consent model

The Customer Experience Guidelines have been designed in consultation with the industry to facilitate standardized sharing of data mandated by the Open Banking Rulebook published by the Central Bank of Bahrain (CBB) in a simple and secure manner.

3. Customer Experience Principles

This section lays out several design and experience principles that form the foundation for customer experience in Open Banking Implementation. The Open Banking customer experience should ensure informed decision making while remaining understandable, intuitive and effective for the user/customer.

3.1. Ownership and Control

For Open Banking, sense of ownership can be achieved by providing appropriate information at the right time to the customer (e.g. knowing the account balance at the point of payment, providing the option to proceed with or to exit the process, or knowing that they can view and revoke consents given when they feel it is appropriate to do so). AISPs, PISPs and ASPSPs should consider how they provide this sense of ownership and control throughout the customer engagement journey, enabling the customers to feel that this is a process that they have chosen and are in charge of.

3.2. Speed and Clarity

Speed should be appropriate to the customer and the journey they are undertaking. Managing and optimising each interaction with speed, clarity and efficiency, but without sacrificing the principles of security and ownership, is of utmost importance to ensure adoption. AISPs, PISPs and ASPSPs need to ensure that customer journeys remain flexible enough to support different customer contexts, expectations and situations and, critically, avoid any unnecessary friction in the completion of any journey.

3.3. Security

AISPs, PISPs and ASPSPs should make sure essential security measures are in place throughout the user journey. In addition to personal data, transactional (data) security is the critical factor to ensure the adoption of Open Banking services.

3.4. Transparency and Trust

It is critical to establish and reinforce trustworthiness throughout the customer journey. The principles of ownership, speed and clarity, and security combine to create a transparent and trusted environment for the customer. AISPs, PISPs and ASPSPs should consider and promote values of trust through every part of their Open Banking customer journeys, to foster understanding, acceptance and adoption of new innovative products and services.

4. The Open Banking Customer Journey

At the core of all Open Banking customer journeys is the mechanism by which the customer gives consent to an AISP/PISP to access account information held at their ASPSPs or to initiate payments from their ASPSP account. The user journey begins with the pre-consent flow, in which the customer chooses the product/service they would like to avail of. Subsequently, the consent request is initiated in the AISP/PISP domain and the user is directed to the domain of the user’s ASPSPs for authentication and authorisation. The ASPSP then responds to the AISP’s account information or PISP’s payment initiation request and redirects the customer back to the AISP/PISP for confirmation and completion of the journey.

The user journey can be divided into the following components:

The pre-consent stage consists of the customer onboarding experience and takes place prior to the Consent Flow. Information regarding the product/ service must be presented in a clear, transparent manner to the user/customer.

Customer consent to share data is central to the Customer Experience Guidelines as it will give users/customers more control of their data; encourage more privacy conscious behaviour, and provide a more positive data sharing experience for users/customers. The Guidelines propose a number of requirements in relation to consent within which the practical guidance on consent design must reside. These requirements have been elaborated upon in detail in each use case.

ASPSPs, AISPs and PISPs must ensure the following before authentication at the ASPSP depending upon the nature of authentication followed:

Redirection based authentication (Web-based/App-based):
- The redirection must take the user/customer to the ASPSP web page (desktop/mobile) or app for authentication purposes only without introducing any additional screens
- ASPSPs should make the user/ customer aware through an intermediary screen that they are being taken to their ASPSP for authentication
- If the user/customer has an ASPSP app installed on the same device, the redirection must invoke the ASPSP’s app for authentication purposes only without introducing any additional screens

Decoupled authentication:
- User/Customer provides a static identifier to the AISP/PISP which is used by the ASPSPs: The AISP/PISP must present the user/customer the authentication options supported by the ASPSPs which in turn can be supported by the AISP/PISP device/channel. The AISP/PISP must request the identifier from the user/customer which is supported by their ASPSP. The AISP/PISP must make the user/customer aware about how this identifier will be used. After the user/customer enters the specified identifier, if the user/customer has an ASPSP app then the ASPSP must notify the user/customer through the ASPSP app for authentication purposes without introducing any additional screens
- User/Customer provides a dynamic identifier generated with their ASPSPs to the AISP/PISP: The AISP/PISP must provide the user/customer information on how the identifier can be generated with their ASPSPs and make the user/customer aware about how this identifier will be used. The user/ customer must be able to easily provide the identifier to the AISP/PISP application. After the user/customer provides the ASPSP app generated identifier to the AISP/PISP then the ASPSP must display the requested information/payment detail within the same session of the ASPSP app. The ASPSP must make the user/customer aware that they have been logged off from the ASPSP app and notify them to check back on the originating AISP/PISP app

3. Authentication and Authorisation

The user/customer needs to go through a strong customer authentication (SCA) at their ASPSPs in order for an AISP/PISP request (i.e. access to information or payment initiation) to be actioned by the ASPSP. The experience available to a user/ customer when authenticating a journey via an AISP/PISP must involve no more steps, delay or friction in the customer journey than the equivalent experience they have with their ASPSPs when interacting directly.

The Bahrain OBF supports both redirection and decoupled authentication to allow a user/ customer to use the same authentication mechanisms while using an AISP or PISP as they use when accessing the ASPSPs directly.

Redirection based authentication: Redirection based authentication has a range of possible experiences for a user/customer based on whether the user/customer has an ASPSP app or not, and the device on which the user/customer is consuming the AISP/PISP service
Decoupled authentication: In decoupled authentication, the user/customer uses a separate, secondary device to authenticate with the ASPSP. This model allows for a number of innovative solutions and has the added benefit of allowing the user/customer to use their mobile phone to authenticate, taking advantage of biometrics for SCA, where they are engaging with an AISP/ PISP through a separate terminal such as a point of sale (POS) device

4. Post Authentication and Authorisation

Once consent has been granted to the AISP/PISP, measures must be put in place to ensure the user/customer is informed.

ASPSPs must have the following measures in place depending upon the nature of authentication:

Redirection based authentication (Web-based and App-based):
- ASPSP must have an intermediary screen which indicates the status of the request and informing the user/customer that they will be automatically taken back to the AISP/PISP
- ASPSP must inform the user/customer on the intermediary screen that their session with the ASPSP is closed
Decoupled authentication:
- The ASPSP must make the user/customer aware that they have been logged off from the ASPSP app and notify them to check back on the originating PISP app

AISPs and PISPs must display the information received from the ASPSP and provide confirmation to the user/customer.

The Open Banking Customer Journey must be read in conjunction with the Customer Experience Guidelines - User Journeys illustrated in each use case to understand the detailed requirements at each stage of the journey.