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 8 Next »

1. Introduction

CBB published an Open Banking rulebook which defines the risks, systems and controls, framework contracts and standards for authentication and communication for participants to adhere to. Several financial institutions in Bahrain participated in implementing the Open Banking framework. Certain gaps were identified with respect to customer experience that are essential to be addressed in order to promote widespread adoption.

In order to explicitly define customer journey and experience, CBB has drafted the Customer Experience Guidelines and the Checklist in consultation with industry expertise.

The Guidelines and the Checklist form 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 Checklist has been developed for ASPSPs and TPPs to assess compliance to this aspect of the Open Banking Implementation Requirements.

The following regulations have been considered and it has been ensured that the Guidelines and the Checklist are consistent with them. The Guidelines must be read in conjunction with the following:

  1. Processes and measures that protect customer data confidentiality and personalised security credentials consistent with Law No. 30 of 2018, Personal Data Protection Law (PDPL) issued on 12 July 2018.

  2. Prevention of anti-money laundering (AML) and combating terrorist financing (CTF).

  3. Module PB: Principles of Business, Paragraph, PB1.1.10, AISPs and PISPs must establish adequate internal controls to safeguard the business, its customers and licensees to which they have online access to.

  4. Volume 1, GR-6 of the CBB Rulebook for conventional banks.

  5. CBB Open Banking Rulebook

  6. Vol 5, Type 7 of the CBB Rulebook for Ancillary Service Providers

2. Customer Experience Principles

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

The Open Banking customer experience must ensure informed decision making while remaining understandable, intuitive and effective. The customer experience must 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. Transparency

It is imperative to provide customers with the right tools and clarity of information at the right time (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 through their journeys, should ensure transparency by clearly communicating the purpose of accessing specific data while ensuring they provide the user/customer with a clear sense of ownership/control over their data.

2. Seamlessness

Seamless journey through Convenient, speedy and intuitive design is a question of execution and interaction. Speed must 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 control, is of utmost importance.

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

3. Security and Reassurance

Explicit clarity and reassurance will be required in relation to data definition, usage, security and above all, protection. AISPs, PISPs and ASPSPs must 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 need to 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 a TPP (AISP or PISP) to access account information held at their ASPSPs (Banks) or to initiate payments from their ASPSPs (Banks) account.

The user journey begins with the pre-consent flow, which illustrates product value and Open Banking value proposition. Subsequently, the consent request is initiated in the AISP/PISP domain. The user/customer 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 a general onboarding experience and takes place prior to the Consent Flow. Customer trust is critical to Open Banking adoption.

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 sit. These requirements have been elaborated upon in detail in each use case

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

  • Redirection based authentication:

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

b.   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 should make the user/customer aware that they will be taken to their ASPSPs page for authentication

  •  Decoupled authentication:

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

b.   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)

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

b.   ASPSPs should make the user/ customer aware through an intermediary screen that they are being taken to their ASPSP for authentication.

  • Decoupled authentication

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

b. User/ Customer provides a dynamic identifier generated with their ASPSPs to the PISP: The user/ customer should 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

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. User/ Customer should 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 should 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 Open Banking Framework 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.

3. Post Authentication and Authorisation

Once consent has been granted to the AISP/PISP, measures should be put in place to ensure the 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): 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.

a.   ASPSP should 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.

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

  • Decoupled authentication:

a.   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 PISPs must display the information received from the ASPSP and provide conformation to the customer.

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

  • No labels