1. Introduction

This section lays out the principles of informed decision-making, providing Users with well-designed experiences (using the principles of control, speed, transparency, security and trust). It also includes information that should be considered to support the protection of vulnerable Users.

LFIs, User-facing TPPs SHOULD design user journeys equivalent to or better than the journeys described in the Standard to deliver the best possible experience and outcomes.

Open Finance products and services MUST therefore enable:

• Informed decision making: User journeys MUST be intuitive and information MUST be easily assimilated to ensure informed user decision making.

• Simple and easy navigation: There MUST be no unnecessary steps, delays or friction in the user journey.

• Parity of experience: The experience available to a User when authenticating a journey via a User-facing TPP SHOULD involve no more steps, delays or friction in the user journey than the equivalent experience they have when interacting directly with their LFI.

• Familiarity and trust: The User MUST only need to use the login credentials provided by the LFI.

2. Customer Journey

Open

At the core of all Open Finance, customer journeys is the mechanism by which the User gives consent to a TPP to access their account held at their LFI for Data Service Requests or Service Initiation requests.

In general, simplified terms, a consent request is initiated in the TPP domain (step 1). The User is then directed to the domain of its LFI for authentication (step 2). Then, once authentication is complete, the LFI will be able to respond to the TPP’s Data Service Requests or Service Initiation Requests and directs the User back to the TPP for confirmation and completion of the journey (step 3).

3. User Experience Principles

The Open Finance user experience MUST ensure informed decision-making while remaining understandable, intuitive and effective. The user experience MUST be shaped and positioned into content and functionality that communicates and facilitates purpose, intent and relevance.

This is especially true in a transactional context where Users MUST know and understand at all times:

• Where they are in a specific process (and what they should expect from that process).

• Where they have come from.

• What options, actions or steps do they have in front of them (if any)

• The (implicit) consequences of taking those actions or next steps.

• An unambiguous signal, feedback and/or response, once that action is taken.

It is essential to move beyond the pure mechanics of the transactional process and into a meaningful, supportive and trusted experience that directly addresses the User’s needs, goals and concerns. This can be achieved in the way a transaction is structured but also in how it is expressed, designed for, and organized around a range of fluctuating human needs.

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

These experience principles are deeply user-centered, they are used to drive and focus design and User Experience (UX) decisions i.e. what kind of widget, interaction, font, color, technology, UX and User Interface (UI) best serves the aspirations and requirements of the business but also meets the needs of the User in simple, effective ways.

It has been shown that in other countries that there are certain recurring themes that Users deeply care about or are worried by. To promote engagement and understanding and ensure adoption, these MUST be addressed, to varying degrees, within each of the Open Finance user journeys described in the Standard.

To support and achieve the goal of creating trust, these themes have been aggregated and synthesized into several driving experience principles for Open Finance. These principles underpin the range of core journeys and key User interactions described throughout the Standard.

 

Open

 

An essential component of trust-building is the provision of Consent Dashboards by the User-facing TPPs and the LFI. Dashboards encapsulate the user Experience principles below and provide a role in reassuring Users about the security of Open Finance-enabled services. In terms of the experience of using a Dashboard, the principles that apply to an authentication journey can be extended to support simple and easy navigation by enabling informed decision-making. Please refer to the Dashboards section to read more.

4. Design to Maximize Transparency to Users

User-facing TPPs MUST:

• Clarify rights and responsibilities describing how the relationship works.

• Investigate and answer additional questions raised.

• Clarify the purpose of data collection and who is responsible for the use.

• Offer detailed explanations for why specific data groups are collected and used.

• Clarify what happens after the period ends.

• Clarify data use and removal after consent is revoked (e.g. what happens to past, present, and future data).

• Ensure all services are available in both Arabic and English.

• Ensure that there is an accurate translation of text to Arabic.

• Ensure the Arabic User Experience adheres to best practices in terms of the adjustments for right to left text.

5. Design to Maximize User Trust

User-facing TPPs MUST:

• Convey strong data security. When required, use fingerprint and face recognition to help drive security and trust.

• When working with trusted bank brands ensure to build in cogitative friction.

• Add support/contact details.

• Specify groups (or types) of 3rd parties, and how they support the service being offered.

• Clarify the intentions and benefits of historical data sharing.

• In all journeys, use the User’s bank logos/icons rather than a generic one to support User familiarity.

• Use simpler, more direct, and less official-sounding language where possible.

6. Maximize the User’s Sense of Control

User-facing TPPs MUST:

• Visually foreshadow stages of the process in advance.

• Give Users control of what data is shared and time frames around this.

• Describe the benefit of sharing with non-essential 3rd parties, but offer the option to de-select them.

• Describe revoke consent to access data (and make it easy).

• Consider navigation with less scrolling and more swiping.

• Allow Users to de-select specific data groups if a reduced service can be offered without them.

7. User in Control

Many User are not yet familiar with Open Finance enabled propositions, Users may not review information sufficiently and may make decisions that they might later wish to reconsider. It is extremely important to minimize unnecessary information and process, and then to package only the most important information in an easily understandable, intuitive manner so that Users can actually assimilate the information and therefore make better-informed decisions.

8. Protection for Vulnerable Users

Users deemed as vulnerable, or in vulnerable circumstances, may be significantly less able to effectively manage or represent their interests than the average User, and more likely to suffer detriment. This may take the form of unusual spending, taking on unnecessary financial commitments or inadvertently triggering an unwanted event. Any User can become vulnerable at any time in their life, for example through serious illness or personal problems such as divorce, bereavement or loss of income.  In these scenarios, it is important to emphasize informed decision making, with appropriate steps and information in online experiences to help those with mental health problems to make informed decisions, understand the potential consequence of their decisions, or even deter a particular course of action.

Entities have a particular responsibility to identify and protect vulnerable Users and SHOULD pay attention to possible indicators of vulnerability at a holistic level and have policies in place to deal with Users where those indicators suggest they may be at greater risk of harm. For those Users identified as vulnerable, the policies applied SHOULD be implemented at the User level, not at the transaction level or not specifically to Open Finance, just as is the case for vulnerable Users using other products provided by the LFI.

LFIs SHOULD take the following steps for vulnerable Users using products that make use of Open Finance:

• Provide support for vulnerable Users by incorporating information from the Open Finance channel. LFIs SHOULD consider this issue holistically, treating Open Finance as they would any other User channel. The LFI, having insight into user behavior, is well placed to provide the appropriate support, recognizing that no single Open Finance user journey SHOULD trigger vulnerability flags to the LFI.

• Provide useful and informative consent dashboards within the LFIs domain that give vulnerable Users the control they need over their financial affairs and access to their account information. Vulnerable Users SHOULD be able to see full details of all the access granted to User-facing TPP the data shared the expiry date and have the ability to revoke their consent.

• It is suggested that a provision SHOULD be made in the LFIs consent dashboard enabling Users to switch on a summary information step as an opted-in choice.

9. Useful Elements in the User Journey

Many Users are prone to skim through the information presented to them when setting up online products because the information is not well presented. In their desire to achieve the promised benefit, insufficient notice is taken of the implications of their actions, or the terms and conditions. It is commonplace to discover, once they have completed the user journey, that they cannot spontaneously describe what they have just agreed to. It has shown that a better understanding can be achieved by carefully designing the user journey. The solution is about the effective, intuitive presentation of information, and not about introducing steps to slow the User down or repeating information. The following methods are the most effective:

• Effective messages and navigation are appropriate to the redirection screens when the User is redirected from the User-facing TPP to the LFI, and then again when the User is redirected back from the LFI to the User-facing TPP. For a User that has granted consent to the User-facing TPP, the redirection screen creates a clear sense of separation as they enter the LFIs domain where they authenticate before clearly being passed back to the User-facing TPP. This provides a familiar and trusted experience to the User and signposts the User’s journey from one domain to the other

• Providing useful information presented in an intuitive and easily consumable way. The principle here is to ensure that the information that the User is presented with is kept to a minimum. If it is unavoidably necessary for the TPP to convey more complex information, it is more likely to be read and understood when presented as a series of smaller amounts of information across more than one screen. This is a much more effective method than the use of a single text-heavy screen.

• Providing supplementary information at specific points in the user journey is useful, helping the User to understand the process as well as ensuring comprehension of a product or offer and its implications. If executed well, it will enhance the user journey and does not lead to an increased propensity to drop-off.

10. Unhelpful Elements in the User Journey

Superfluous information, poor or confusing choice of words, repetition, large amounts of text, too many steps or avoidable delays in the user journey can lead to frustration, an even greater tendency to skim, and ultimately increase User drop-off. The following unhelpful elements MUST be avoided: 

• A User authentication journey that takes too long and requires the use of separate devices such as one-time password generators, especially if applied multiple times in the user journey.

• Where there are fewer screens but a significant amount of text on the screen. This is particularly evident when this requires Users to scroll up and down the screen to progress the user journey.

• Providing superfluous information that does not add to the User’s understanding or trust, especially when presented in a separate step or screen.

• Delays such as slow loading times, as well as web pages or apps that have not been effectively debugged, and unexpected crashing of web pages or apps.

• Inappropriate use of language, particularly language which may create a level of concern, uncertainty and doubt when going through the user journey.

• The use of language that is too long, complex or legalistic to be easily understood when going through the user journey.

• Asking for the same information twice, and asking for information for which there is no obvious purpose, e.g. replaying the consent to the User that was granted to the TPP, or asking for a PIN when it is not needed.

• Forcing the User to open a new browser window during the user journey, and having to toggle between screens to progress.

• Introducing the requirement for a User to input information that they don’t readily have to hand, such as unique User reference numbers

• Requesting input of information that could reasonably be expected to be pre-populated once the User has authenticated.

• Failing to differentiate between new Users and experienced regular Users who may want to shorten the user journey without exposing themselves to risk.

11. Other Rules for User Journeys

• The User-facing channel SHOULD be optimized for various devices, such as desktops, tablets, and smartphones, to ensure accessibility.

• The User-facing channel MUST be bilingual to support both Arabic and English.

• TPPs MUST provide Users with a straightforward and user-friendly interface that offers clear instructions, helpful tips, and easy-to-understand labels throughout the whole process.

• TPPs MUST provide easy-to-access options for User support, such as chat, email, and phone, to ensure that Users can easily access help and receive prompt assistance.

• TPPs MUST provide their trading name to the Users and the LFIs. If applicable, they must also disclose the names of other parties they offer their services to.

• TPPs MUST ensure that Users clearly understand the different elements of the Consent by providing a concise explanation and illustrative example for each element.

• LFIs and TPPs MUST implement their customer experience screens in line with what is provided in each Customer Experience section of the Standard for the relevant functionality. This includes colors, branding, spacing and component design.

  • The assets in the folder are provided to ensure alignment with the customer experience screens provided in the Standard

• LFIs and TPPs must implement their customer experience screens in line with AlTareq Brand Guidelines

• LFIs and TPPs MUST NOT make use of multi-press buttons whereby a User is required to press a button more than once for the same intended action

• LFIs and TPPs MUST NOT create friction in the form of additional requests for confirmations

• The User MUST go through an MFA with the LFI only once before they authorize the consent. There should be no additional authentication required.