Open Banking stands to unlock greater value through proliferation of new business models, new market entrants, increased monetization opportunities, scaled up digital banking and most importantly greater value to customer in usage of financial products and services.
Bahrain has already established itself as a leading financial services and FinTech hub in the Middle East, owing to the pro-innovative stance taken by the Central Bank of Bahrain (CBB) to be at the forefront. We believe the Bahrain Open Banking Framework has been designed to further strengthen this position and would serve as a catalyst to growth.
Keeping this in mind, we have designed the Bahrain OBF, so that the Bahrain market can reap the benefits of Open Banking and can scale up the opportunities associated with the same as the system matures.

PISP offer payment initiation services to users/customers as part of Open Banking. On the other hand, EFTS is a payments network/system that enables payments between two IBAN accounts in Bahrain. Thus both are independent of each other. For example, a user/customer may initiate a payment through a PISP application, and the actual payment will be handled/settled by the EFTS system.

Security has always been the primary focus area for Open Banking.

• Bank level Security: Open Banking uses rigorously tested software and security systems. You’ll never be asked to give access to your bank login details or password to anyone other than your own bank or building society.

• Accreditation: Only third party providers regulated by the CBB can use Open Banking.

• User/ Customer is always in charge: you choose when, for what purpose and for how long, you give access to your data.

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

When a User/Customer signs up for a service, the AISP/PISPs 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.

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

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

An idempotency key is used to guard against the creation of duplicate resources when using the POST API endpoints (where indicated).

If an idempotency key is required for an API endpoint:

• The x-idempotency-key provided in the header must be at most 40 characters in size. If a larger x-idempotency-key length is provided, the ASPSP must reject the request with a status code is 400 (Bad Request).

• The AISP/PISP must not change the request body while using the same x-idempotency-key. If the AISP/PISP changes the request body, the ASPSP must not modify the end resource. The ASPSP may treat this as a fraudulent action.

• The ASPSP must treat a request as idempotent if it had received the first request with the same x-idempotency-key from the same AISP/PISP in the preceding 24 hours.

• The ASPSP must not create a new resource for a POST request if it is determined to be an idempotent request.

• The ASPSP must respond to the request with the current status of the resource (or a status which is at least as current as what is available on existing online channels) and a HTTP status code of 201 (Created).

• The ASPSP may use the message signature, along with the x-idempotency-key to ensure that the request body has not changed.

If an idempotency key is not required for an API endpoint:

• The ASPSP must ignore the idempotency key if provided.

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.

Feel free to visit our confluence page for more updates. CBB will update this page on a periodic basis.