Overview

To ensure all parties are protected and have clarity, SAMA has provided a list of things you need to comply with as part of the KSA Open Banking Standard. Lean handles many of those requirements for you but you will need to handle some parts yourself. The following explains these requirements.

Bank account connection flow

📘

Language support

The account connection flow needs to be provided both in Arabic and English

Consent explanation before connection

Before you take you customer through Lean's LinkSDK to gather their consent, you are required to provide clarity to your customers of a few details about the consent:

Each of the numbers marked in the mock screen above are explained below:

In addition, you will have to meet the following requirements:

• You must include any charges that the user needs to pay for connecting their account
• You must include both your brand name and legal name

Sample screen

The second screen of the following demo shows how the screen would look like for a personal finance application:

T&Cs and Privacy Notice

You are required to understand any relevant regulatory obligations and that these are included within your T&Cs and Privacy Notice.

Confirmation and errors

📘

To handle success and errors, for the cases your customer uses app redirect to consent, you will need to pass the corresponding URLs to fail_redirect_url and success_redirect_url as part of the connect() flow in the LinkSDK. For the cases of decoupled auth flow, you will need to handle the callback from the LinkSDK.

If there is an error at any point in the consent setup journey, you are required to inform the user of how to retry, cancel or any steps they can take. If the consent is set up successfully, you you are required to inform the user of this and any next steps needed.

Example success and fail screens:

Consent management

📘

Note that is only applicable if you are requesting open ended or long lived consent. If you are requesting a one time consent (i.e.: you are a fourth party), you will not need to implement consent management so you can skip this section.

You are required to build a way in which your customers can manage the consents they have granted you (Consent Dashboard). This includes allowing your customers to view all consents and revoke them.

It is suggested to provide an overview screen (Consent Dashboard home page) which lists high level information for all consents, and a detailed page for each consent (Consent Dashboard detailed page).

Consent Dashboard home page

📘

You can use the GET entities API that Lean provides to display the information to the end user (see API)

You are required show the following for each of the consents:

• bank name (or nickname if used)
• account type (if provided)
• the expiry date for when the consent will end
• the date and time of the last occasion when data was synced from the connected account
• a status flag that is “Active” (you can only use the terms "Active", for active consents, and "Expired", for inactive consents)
• warnings or alerts if consent is close to expiry
• a manage button that allows your customer to revoke, i.e. disconnect (see more detail in Revocation journey section) or view details of the consent

You are required make available a list of consents that have been cancelled or expired so that the customer has a record of old consents.

Consent Dashboard detailed page

📘

You can use the GET entity API that Lean provides to display the information to the end user (see API)

You are required show the following for each of the consents:

• bank name (or nickname if used)
• account type (e.g. current account)
• account number (or other product identifier depending on the account type e.g. PAN for credit cards)
• data groups being accessed: using the structure and language recommended in the section Permissions of this document; present the data at a data group level and allow the customer to expand the level of detail to show each Data Permission.
• the purpose of the data sharing
• the date the consent was granted
• the expiry date and time of the consent
• the purpose for which the data will be used
• where the request is for multiple product types (you should explain to the client the product type to which it applies or state that it is shared across multiple product types)

Revocation journey

📘

You can use the DELETE consent API that Lean provides to revoke the consent for an end user (see API)

As stated in the Consent Dashboard home page section, you are required to allow your customer to revoke the consents they have provided you with. For a visual representation of this, see Allowing your customers to revoke consent

The following is a list of things required for this process:

• make clear what will happen to the already-obtained data once the consent is cancelled by the customer
• allow customers to cancel the consent they have provided easily and without obstruction or excessive barriers
• confirm what happens to any existing data that you has already retrieved (be fair and transparent about how existing data is processed and that data that is no longer required is deleted, where appropriate)
• inform the bank the consent has been revoked; the easiest way for you to do this is to use the Consent deletion API that Lean provides

Consent renewal

For consents that are open-ended, you are required to reconfirm consent approval with the customer within twelve months of the last consent approval (no need for your customer to go through the bank connection flow).

You will face 3 different scenarios:

• if your customer approves the consent, no further action is required by you
• if your customer revokes the consent, you are required to revoke the consent
• if your customer does not action the consent, and the consent exceeds 12 months, you are required to set the consent to expired

Permissions

You will need to share with your users the permissions they will or have consented to. Permissions are composed of two parts:

• Permission details, represents the data you will get access to and has a 1:1 mapping with the permissions within Lean's platform
• Data group, permission details are grouped into data groups to make it easier to display to your customers

Both permission details and data groups MUST be shown to the customer and the language MUST be exactly as described below.

The data groups are shown below:

In the following table, we have mapped all permissions in the Lean platform (in the way you pass them to the SDK) to their Data group and Permission details: