Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Version Control

 

Version

Change Date

Description of Changes

Bahrain OBF v1.0

25th Aug 2020

Nil

1. Introduction

Customers will use Open Banking enabled products and services if:

  1. Their user experience and the interplay between Third Party Platforms, including but not restricted to Account Information Service Providers (AISP) and Payment Initiation Service Providers (PISP), and Account Service Payment Service Providers (ASPSP) is seamless as is possible;

  2. Information is presented in an intuitive manner that is easy to comprehend and allows them to make informed decisions; and

  3. Sufficient measures are taken to gain customer trust through a secure consent model.

The Customer Experience Guidelines serve as an enabler to provide customers with a seamless experience. The Customer Experience Guidelines have been designed to facilitate standardized sharing of data mandated by the Open Rulebook published by the Central Bank of Bahrain (CBB) in a simple and secure manner. 

In order to explicitly define customer journey and experience, the CBB has drafted the Customer Experience Guidelines in consultation with the industry. The 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, non-functional requirements and dispute resolution practices. The Guidelines must be read in conjunction with the existing regulations in Bahrain.

2. Customer Experience Principles

The CBB has laid emphasis on a number of design and experience principles while developing the Guidelines. This section lays out certain standards that form the foundation to customer experience in Open Banking Implementation.  

The Open Banking customer experience should ensure informed decision making while remaining understandable, intuitive and effective. The customer experience should be shaped and positioned into content and functionality that clearly communicates and facilitates purpose, intent and relevance.


A series of guiding principles are outlined here that can be, through careful design, baked into a process or transaction, and dialled up and down where certain interactions become more critical.

1. Control

For Open Banking, control comes from providing the right tools and clarity of information at the right time to the customer (e.g. knowing the account balance at the point of payment, 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 specific optionality throughout - enabling customers to feel this is a process they are both choosing and in charge of.

2. Speed

Speed should be appropriate to the customer and the journey they are undertaking. Convenient, speedy and intuitive design is a question of execution and interaction.

Managing and optimising each interaction with speed, clarity and efficiency, but without sacrificing the principles of security and control, is of utmost importance.

The user journey should support informed decision making through comprehension and clarity, allowing customers to, above all, move at a pace that suits them.

3. Security

Explicit clarity and reassurance should be in relation to data definition, usage, security and above all, protection. AISPs, PISPs and ASPSPs should make sure essential measures are in place throughout the user journey.

As a new service, all security messaging should be clear and reassuring in tone.

4. Trust

Customers are aware of the risks of sharing personal information.

It is therefore critical to establish and reinforce trustworthiness - trust in the service provider, trust in the transactional process and trust in the role and relationship with their ASPSPs.

The principles of control, speed and security combine to create a 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.

3. 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. The user is then directed to the domain of its 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 thus 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 customer.

2. Consent

Customer consent to share data is central to the Customer Experience Guidelines as it will give customers more control of their data, encourage more privacy conscious behaviour, and provide a more positive data sharing experience for 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.

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

  • In case of redirection based authentication:

    • Web- based: The redirection must take the user/customer to the ASPSPs web page (desktop/mobile) for authentication purposes only without introducing any additional screens.

    • App- based: If the user/customer has an ASPSP app installed on the same device, the redirection must invoke the ASPSPs’ app for authentication purposes only without introducing any additional screens. 

AISP/PISP must make the user/customer aware that they will be taken to their ASPSPs page for authentication.

  •  In case of 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 customer which is supported by their ASPSP. The AISP/PISP must make the user/customer aware about how this identifier will be used.

    • 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.

ASPSPs must ensure the following for a seamless journey depending upon the nature of authentication followed :

  • Redirection based authentication (Web-based and 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.

  • 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 customer which is supported by their ASPSP. The AISP/PISP must make the user/customer aware about how this identifier will be used.

    • 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.

ASPSPs must ensure the following for a seamless journey depending upon the nature of authentication followed:

  • In case of redirection based authentication (Web-based and 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.

  • In case of decoupled authentication:

    • User/customer provides a static identifier to the AISP/PISP which is used by the ASPSPs: 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 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 payment request 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 user/ customer must be able to use the elements they prefer to authenticate with their ASPSPs if supported when interacting directly with their 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.

  • In case of 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.

  • In case of 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.

3. Post Authentication and Authorisation

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

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

  • In case of redirection based authentication (Web-based and App-based):

    • ASPSP must have intermediary screen which indicates the status of the request and informing the user/customer that they will be automatically taken back to the PISP.

    • ASPSP must inform the user/customer on the intermediary screen that their session with the ASPSP is closed.

  • In case of 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 conformation to the 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.

CENTRAL BANK OF BAHRAIN © 2020

  • No labels