Bahrain OBF is the Open Banking Framework that supports the implementation of open banking in Bahrain. It will promote innovation while at the same time ensure highest standards are adopted in addressing customer data confidentiality, data security and privacy, safety and robustness of Bahrain’s financial system.
Bahrain OBF has been developed considering the relevant use cases (payments as well as account information sharing) that have several business opportunities for the ASPSPs and third party providers to cater to the customer’s unique needs. Bahrain OBF covers the associated technical and non-technical elements namely customer experience guidelines, user/customer journeys, API specifications, operational guidelines, and security standards and guidelines.

Bahrain OBF focuses on several key guiding principles:

• Create Value: Focus on delivering true value without placing undue burdens on any OB participant.

• Enhance Transparency: Ensure customers are fully informed of their rights and responsibilities regarding the transfer, possession, and use of their data.

• Ensure Safety: Deliver a Framework while keeping customer convenience, safety and security at the center.

• Adoption: Ensure a seamless economy wide adoption by balancing regulation, participation, and speed to market with the scope of products and/or data.

Bahrain OBF is a set of standards and guidelines that will enable Open Banking participants to offer a variety of Open Banking services in Bahrain. This Framework has to be read in conjunction with the CBB Rulebook. Guidelines drafted under Bahrain OBF are complementary to and not a replacement of any existing legal or regulatory requirements as per the CBB Rulebook.

Bahrain OBF will be updated on a periodic basis to incorporate industry feedback, changes to standards or guidelines, addition of new innovative use cases, and modifications to the local and regulatory and Open Banking landscape.
Changes made to any section will be documented on the version control table maintained for each page.

Any Open Banking participant supplying or accessing data has obligations under existing legal and regulatory frameworks in Bahrain, such as the CBB Rulebook and PDPL. Guidelines drafted under Bahrain OBF are complementary to and not a replacement of any existing legal or regulatory requirements in Bahrain.
All CBB licensees are subject to the provisions of the PDPL of Bahrain and ambiguities, if any should be discussed ahead of implementation with the CBB. Further, Open Banking operates strictly within the context of explicit customer consent. All licensees must consider the PDPL provisions while finalizing the business models, the operational standards and other relevant aspects.

No, there is no additional charge for using Open Banking as a service. However, some accredited third party providers may decide to charge you for their products/solutions/services customized for your needs.

No. You have to enable online or mobile banking services for your account to avail Open Banking services.

PISPs offer payment initiation services to the users/customers as part of Open Banking. EFTS is a payments network/system that enables payments between two IBAN accounts in Bahrain. The execution of the payment under the PISP service will be handled/settled by the existing EFTS system. For example, a user/customer may initiate a payment through a PISP application, to transfer funds from his/her bank account to a beneficiary and the actual payment will be handled/settled by the EFTS system.

Under Bahrain OBF, third party providers have both read and write access depending on the nature of service they provide.

• Read access allows the data recipient to obtain copies of customers’ financial data and use it for such activities as data aggregation (for example – AIS - account aggregations services).

• Write access allows data recipient to initiate payments on behalf of the user/customer (for example – PIS - payment initiation services).

Safety and Security of user/customer data has always been the primary focus area for Bahrain Open Banking:

• The user/customer is always in control: The user/customer can choose when, for what purpose and for how long, to give access to his/her data.

• Accreditation: Only third party providers regulated by the CBB can provide Open Banking services in Bahrain.

• Existing Bahrain Regulations: All the existing Bahrain regulations for data security, storage, dispute etc. will continue to be applicable to Open Banking services as well.

• Security: All Open Banking participants should comply with the Security Standards and Guidelines as part of the Bahrain OBF.

The principles of control, regulation and security combine to create a trusted Open Banking environment for the user/customer.

No. It is always your decision and you will need to give your explicit consent to avail Open Banking services. You can avail of Open Banking services only if you give permission to an accredited third party provider to use your data or initiate a payment on your behalf.

Yes. You need to give an explicit consent to use the Open Banking services of a third party provider. Amongst other things, the consent will clearly state the purpose for which it is granted and the time period for which it will be used.

Access to data is driven by consent and the purpose for which access was granted in first place. There are 2 ways in which you can revoke access to your data:

• You can withdraw your consent directly on the AISP’s/PISP’s application or website; or

• You can inform your bank, that you no longer want the AISP’s/PISP’s application or website to have access to your data

Data can only be stored by the AISP/PISP for the purpose for which it was accessed under an explicit consent. Hence, once you cancel/revoke access to your data, the AISP/PISP has to delete that data and it cannot be used any further.

No. You will always need to approve any payment made from your account. No payment can be made without your authorisation.

If under some circumstances, money has been transferred from your account without your authorisation for transferring it, contact your bank as soon as you become aware about this transaction. Depending on the circumstances, they may be able to refund back the money.

Contact the bank or third party provider immediately, if you believe that your data has been used incorrectly or has been misused.

All Open Banking participants should use the existing infrastructure for disputes handling process and dispute resolution.

When a user/customer signs up for a service, the AISP/PISP must request for explicit consent from the user/customer in order to permit access to data that may be essential only for that specific service. All consent requests should indicate in a clear and specific manner, the details, scope, objectives and implication of providing such consent. Necessary safeguards should be established by the AISP/PISP to ensure that the user/customer reads the terms and conditions before providing explicit consent. Details on the consent message, structure and language are specified in detail as part of Bahrain OBF.

Open Banking participants should follow archiving policies based on existing Bahrain regulatory and legal requirements.

The first step is to discuss your complaint directly with AISP/PISP or an ASPSP. If you believe you are not satisfied with their response, you can contact CBB by submitting the Complaint Form available on https://www.cbb.gov.bh/complaint-form/

Only accredited third party providers and ASPSPs are allowed to offer Open Banking services in Bahrain.
Anyone who wishes to receive user/customer data to offer products or services to users/customers must be accredited with the CBB.
To become accredited, a person must apply to the CBB. The CBB will review the application and duly advise the applicant in writing when it has:

• Granted the application without conditions;

• Granted the application subject to conditions specified by the CBB; or

• Refused the application, stating the grounds on which the application has been refused and the process for appealing against that decision

Accreditation criteria has been laid down and explained in detail in the Authorisation Module of Volume 5 of the CBB Rulebook.

Anyone who wishes to know about the accreditation of a third party provider may do so by checking the list of accredited third party providers on the licensing directory available on the CBB website. In addition to the CBB website, the third party provider should clearly state their accreditation status.

The CBB may amend or revoke a license in any of the following cases:

• If the licensee fails to satisfy any of the license conditions;

• If the licensee violates the terms of the CBB Rulebook;

• If the licensee fails to start business within six months from the date of the license;

• If the licensee ceases to carry out the licensed activity in the Kingdom;

• The legitimate interests of the customers or creditors of a licensee required such amendment or cancellation

A REST resource should have a unique identifier (e.g. a primary key) that may be used to identify the resource. These unique identifiers are used to construct URLs to identify and address specific resources.

However, considering that some of the resources described in these specifications do not have a primary key in the system of record, the Id field will be optional for some resources.

An ASPSP that chooses to populate optional Id fields must ensure that the values are unique and immutable.

All date-time fields in responses must include the timezone. For Example:

The API allows the AISP to ask an ASPSP to create a new account-access-consent resource.

All dates in the query string are represented in ISO-8601 date-time format and must not include the timezone. For example:

All dates in the HTTP headers are represented as RFC 7231 Full Dates. An example is below:

All dates in the JWT claims are expressed as a JSON number, representing the number of seconds from 1970-01-01T0:0:0Z as measured in GMT until the date/time.

The path of the URI must follow the structure below

• [participant-path-prefix]/open-banking/[version]/[resource-group]/[resource]/[resource-id]/[sub-resource]

This consists of the following elements:

• [participant-path-prefix]
  An optional ASPSP specific path prefix.

• open-banking
  The constant string "open-banking".

• [version]
  The version of the APIs expressed as /v[major-version].[minor-version]/.

• [resource-group]
  The resource-group identifies the group of endpoints, to access the API (as "aisp", "pisp").

• [resource]/[resource-id]
  Details the resource.

• [sub-resource]
  Details the sub-resource.

An ASPSP must use the same participant-path-prefix and host name for all its resources.

Examples:

• https://xyz.com/apis/open-banking/v1.1/pisp/domestic-payments

• https://xyz.com/apis/open-banking/v1.1/aisp/account-access-consents

• https://xyz.com/apis/open-banking/v3.1/aisp/accounts

• https://xyz.com/apis/open-banking/v3.1/aisp/accounts/1234

• https://xyz.com/apis/open-banking/v3.1/aisp/accounts/1234/transactions

An ASPSP must provide limited support of filtering on GET operations that return multiple records.

The filter parameters, are always specific to particular field(s) of the resource, and follow the rules/formats defined under the resource's data dictionary.

In case of DateTime type filter parameters, values must be specified in ISO8601 format. If the DateTime contains a timezone, the ASPSP may ignore the timezone component.

The filter values will be assumed to refer to the same timezone as the timezone in which the resource is maintained.

An ASPSP MAY provide a paginated response for GET operations that return multiple records.

In such a situation, the ASPSP MUST:

• If a subsequent page of resource records exists, the ASPSP must provide a link to the next page of resources in the Links.Next field of the response. The absence of a next link would indicate that the current page is the last page of results.

• If a previous page of resource records exists, the ASPSP must provide a link to the previous page of resources in the Links.Prev field of the response. The absence of a prev link would indicate that the current page is the first page of results.

For a paginated responses, the ASPSP may ensure that the number of records on a page are within reasonable limits, the minimum and maximum level for number of records may be decided based on agreement between ASPSP and AISP/PISP.

Additionally, the ASPSP MAY provide:

• A link to the first page of results in the Links.First field.

• A link to the last page of results in the Links.Last field.

• The total number of pages in the Meta.TotalPages field.

As with all other responses, the ASPSP MUST include a "self" link to the resource in the Links.Self field as described in the Links sections.

This standard does not specify how the pagination parameters are passed by the ASPSP and each ASPSP may employ their own mechanisms to paginate the response.

If the original request from the AISP included filter parameters, the paginated response must return only results that match the filter.

ASPSPs are not expected to implement pagination with transaction isolation. The underlying data-set may change between two subsequent requests. This may result in situations where the same transaction is returned on more than one page.

This flow assumes that the following steps have been completed successfully:

• Step 1: Request Account Information

• Step 2: Setup Account Request

• Step 3: Authorise Consent

The AISP attempts to provide an expired or missing access token to the ASPSP in an attempt to Request Data

This flow assumes that the following Steps have been completed successfully:

• Step 1: Request Account Information

• Step 2: Setup Account Request

• Step 3: Authorise Consent

The AISP provides a malformed request to the ASPSP in an attempt to setup an Account Request.

This flow assumes that the following Steps have been completed successfully:

• Step 1: Request Account Information

• Step 2: Setup Account Request

• Step 3: Authorise Consent

The AISP provides a (valid) access token which does not have a valid scope (or link to the correct Permissions) to Request Data.

This flow assumes that the following Steps have been completed successfully:

• Step 1: Request Account Information

• Step 2: Setup Account Request

• Step 3: Authorise Consent

The AISP provides a (valid) access token which is used to generate a burst of multiple requests to retrieve an Accounts resource.

The ASPSP may optionally choose to return a 429 Response.

This flow assumes that the following Steps have been completed successfully:

• Step 1: Request Account Information

• Step 2: Setup Account Request

• Step 3: Authorise Consent Flow fails to succeed due to the USER/CUSTOMER providing invalid credentials to the ASPSP, resulting in no Authorization Code being generated.

The confluence pages will be updated on a periodic basis to keep the Open Banking participants informed on new developments.

For any general enquiry on Open Banking, kindly submit the general enquiry form available on https://www.cbb.gov.bh/general-enquiry-form/