Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

...

...

...

...

...

General

Security has
Expand
titleHow do I know Open Banking is safe?
What is the background behind setting up of the Bahrain’s Open Banking Framework (Bahrain OBF)?

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.

Expand
titleWhat is Bahrain Open Banking Framework (Bahrain OBF)?

A holistic Open Banking framework that will support the evolution of innovation while continuously addressing issues to protect, maintain and bolster the safety and robustness of Bahrain’s financial system.
Bahrain OBF will focus on several key guiding principles while designing its Open Banking Framework:
• 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

Expand
titleWhat will happen to the existing laws on data privacy such as PDPL? (Will my data be continued to be governed by existing Bahrain laws on data privacy such as PDPL?)

Any participant supplying or accessing data already has obligations under existing legal and regulatory frameworks in Bahrain, such as the Personal Data Protection Law (PDPL) of 2018. Guidelines drafted under Bahrain OBF are complementary to and not a replacement of any existing legal or regulatory requirements in Bahrain.
CBB licensees will be subject to the provisions of the Personal Data Protection Law (PDPL) of Bahrain. Any ambiguities should be discussed ahead of implementation of the contractual arrangements and raised with the CBB. Open banking operates strictly within the context of explicit customer consent. The PDPL provisions must be borne in mind while finalizing the business models, the operational standards and other relevant aspects.

Expand
titleAs a customer do I have to pay any additional charge for using Open Banking services?

No, there is no additional charge for using Open Banking. However, some accredited third party providers may choose to charge you for their products and services.

Expand
titleCan I use Open Banking if I don’t use online banking?

No. To use Open Banking you need online or mobile banking services activated for your account.

Expand
titleIs there any relation between the EFTS process and the PISP service under Open Banking?

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

Expand
titleHow do I know Open Banking is safe?

Security has always been the primary focus are 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.

...

Expand
titleHow do I control who has access to my information??

You will always be in control. You decide what information you wish to share with which third party. You choose which accredited third party provider you want to use. The ultimate control of your information will always be with you.

...

Expand
titleI think my data has been used incorrectly or incorrect data has been used. What can I do?

Contact the bank or third party provider you believe have misused your data immediately. If you think you have been a victim of identity theft, immediately report it to your bank. 

...

Restful APIs

The API adheres to RESTful API concepts where possible and sensible to do so.

However, the priority is to have an API that is simple to understand and easy to use. In instances where following RESTful principles would be convoluted and complex, the principles have not been followed.

References:

  • The highest level Data Description Language used is the JSON Schema : http://json-schema.org/

  • Best Practice has also been taken from the Data Description Language for APIs; JSON API : http://jsonapi.org/

  • The Interface Description Language used is the Swagger Specification version 3.0.0 (also known as Open API) : http://swagger.io/

ISO 20022

In keeping with that requirement, the API payloads are designed using the ISO 20022 message elements and components where available.

The principles we have applied to re-use of ISO message elements and components are:

  • Only elements that are required for the functioning of the API endpoint will be included in the API payload. API endpoints are defined for specific use-cases (not to be generically extensible for all use-cases).

  • We will modify ISO 20022 elements where the existing standard does not cater for an API context (such as filtering, pagination etc.).
    Expand
    Expand
    titleWhat are the Design principles concept has been used in CBB API?
    titleWhy should anyone apply for accreditation?

    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

    Expand
    titleWhat are the criteria for accreditation?

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

    Expand
    titleHow do I know if the third party provider is an accredited entity or not?

    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.

    Expand
    titleWhat happens when an accredited entity does something wrong?

    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

    How will Open Banking disputes be managed?

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

    Expand
    titleWhat is the mechanism required to obtain consent from the User/Customer?

    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.

    Accreditation

    Expand
    titleWhy should anyone apply for accreditation?

    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

    Expand
    titleWhat are the criteria for accreditation?

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

    Expand
    titleCan a bank apply to become an AISP/PISP?

    The CBB would be licensing third party providers to offer Open Banking service to banks’ customers in Bahrain. All participants that use Open Banking to offer products and services in Bahrain must be accredited and regulated by the CBB.

    Thus, any person/entity, including banks, that wishes to offer such services would first need to approach CBB for an AISP/PISP license.

    Expand
    titleHow do I know if the third party provider is an accredited entity or not?

    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.

    Expand
    titleWhat happens when an accredited entity does something wrong?

    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

    API Specification

    Expand
    titleWhat is Idempotency?

    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.

    ...

    Expand
    titleList of HTTP Status Codes

    The following are the HTTP response codes for the different HTTP methods, across all Read/Write API endpoints.

    Situation

    HTTP Status

    Notes

    Returned by POST

    Returned by GET

    Returned by DELETE

    Returned by PUT 

    Returned by PATCH 

    Request completed successfully

    200 OK

    PUT will be specified to return the updated resource. A 200 status code is therefore appropriate.

    No

    Yes

    No

    Yes

    Yes

    Normal execution. The request has succeeded.

    201 Created

    The operation results in the creation of a new resource.

    Yes

    No

    No

    No

    No

    Delete operation completed successfully

    204 No Content

     

    No

    No

    Yes

    No

    No

    Request has malformed, missing or non-compliant JSON body, URL parameters or header fields.

    400 Bad Request

    The requested operation will not be carried out.

    Yes

    Yes

    Yes

    Yes

         Yes

    Authorization header missing or invalid token

    401 Unauthorized

    The operation was refused access.
    Re-authenticating the User/Customer may result in an appropriate token that may be usedRequest

    The requested operation will not be carried out.

    Yes

    Yes

    Yes

    Yes

         Yes

    Token has incorrect scope or a security policy was violated.

    403 ForbiddenAuthorization header missing or invalid token

    401 Unauthorized

    The operation was refused access.
    Re-authenticating the User/Customer may result in an appropriate token that may be used

    Yes

    Yes

    Yes

    Yes

    Yes

    The AISP/PISP tried to access the resource with a method that is not defined

    404Not found

     

    used.

    Yes

    Yes

    Yes

    Yes

    Yes

    The AISP/PISP tried to access the resource with a method that is not supported.

    405 Method Not Allowed

     

    Yes

    Yes

    Yes

    Yes

         Yes

    The request contained an Accept header other than permitted media types and a character set other than UTF-8

    406 Not Acceptable

     Token has incorrect scope or a security policy was violated.

    403 Forbidden

    The operation was refused access.
    Re-authenticating the User/Customer may result in an appropriate token that may be used

    Yes

    Yes

    Yes

    Yes

    Yes

    The operation was refused as too many requests have been made within a certain timeframe.

    429 Too Many Requests

    ASPSPs may throttle requests when they are made in excess of their fair usage policy.
    ASPSPs must document their fair usage policies in their developer portals.
    The ASPSP must respond with this status if it throttles the request.
    The ASPSP should include a Retry-After header in the response indicating how long the AISP/PISP must wait before retrying the operation.

    Yes

    Yes

    No

    Yes

    Yes

    Something went wrong on the API gateway or micro-service

    500 Internal Server Error

    The operation failed.AISP/PISP tried to access the resource with a method that is not defined

    404Not found

     

    Yes

    Yes

    Yes

    Yes

    Yes

    The AISP/PISP tried to access the resource with a method that is not supported.

    405 Method Not Allowed

     

    Yes

    Yes

    Yes

    Yes

         Yes

    The request contained an Accept header other than permitted media types and a character set other than UTF-8

    406 Not Acceptable

     

    Yes

    Yes

    Yes

    Yes

    Yes

    An ASPSP MAY return other standard HTTP status codes (e.g. from gateways and other edge devices) as described in RFC 7231 - Section 6.

    ASPSPs must respond with error response in the OAuth/OIDC flow with mandatory alignment of the error codes to those specified in OpenID Connect Core Specification Section 3.1.2.6.

    ASPSPs must respond with Open Banking Error Response Structure for all errors during API Calls.

    The operation was refused as too many requests have been made within a certain timeframe.

    429 Too Many Requests

    ASPSPs may throttle requests when they are made in excess of their fair usage policy.
    ASPSPs must document their fair usage policies in their developer portals.
    The ASPSP must respond with this status if it throttles the request.
    The ASPSP should include a Retry-After header in the response indicating how long the AISP/PISP must wait before retrying the operation.

    Yes

    Yes

    No

    Yes

    Yes

    Something went wrong on the API gateway or micro-service

    500 Internal Server Error

    The operation failed.

    Yes

    Yes

    Yes

    Yes

    Yes

    Expand
    titleDoes GET operation supports filtering?

    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.

    ...

    Expand
    titleWhat are the Archiving policies?

    Archiving of resources will be for ASPSPs to define based on their internal Legal and Regulatory ASPSPs should define archiving policies based on existing Bahrain regulations and their internal legal requirements.

    Expand
    titleWhat is Supplementary Data?

    A number of resources in the specification include a section for Supplementary Data. This is intended to allow ASPSPs to accept or provide information in a request or response that is not catered for by other sections of the resource definition.

    The Supplementary Data section is defined as an empty JSON object in the specification.

    Wherever used, an ASPSP must define and document (on their developer portal) their own structure, usage and (mandatory/optional) requirements for Supplementary Data.

    An ASPSP must not use Supplementary Data if an element already exists in the OBF standard that fulfils the requirement.

    Expand
    titleWhat will be the error flow if the access token is missing or expierdthe access token is missing or expierd?

    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

    Image Added

    Expand
    titleWhat will be the error flow if request payload is incomplete or malformed?

    This flow assumes that the following steps 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 provides a malformed request to the ASPSP in an attempt to setup an Account Request Data.

    Image RemovedImage Added

    Expand
    titleWhat will be the error flow if request payload is incomplete or malformedaccess token scope is missing or invalid?

    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.

    Image Removed

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

    Image Added

    Expand
    titleWhat will be is the error flow if access token scope is missing or invalidthere is sudden burst of API requests?

    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.

    Image Removed

    is used to generate a burst of multiple requests to retrieve an Accounts resource.

    The ASPSP may optionally choose to return a 429 Response.

    Image Added

    Expand
    titleWhat is will be the error flow if there is sudden burst of API requestsconsent authorisation has failed?

    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.

    Image Removed

    Expand
    titleWhat is the error flow if consent authorisation is failed?

    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.

    Image Removed

    ...

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

    Image Added

    Further Information

    Expand
    titleHow can I stay informed on new Open Banking updates or news?

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

    Expand
    titleWho can I reach out to in case of any general enquiry regarding Open Banking?

    Feel free to contact CBB for any enquiry on Open Banking by submitting a general enquiry form available on https://www.cbb.gov.bh/general-enquiry-form/.

    Feel free to write to us at bobf@cbb.gov.bhfor inquiry or feedback you may have related to Open Banking.
    Expand
    titleHow can I stay informed on new Open Banking updates or news?

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

    Expand
    titleIs there any email ID where I can inquire about anything related to Open Banking?
    complain about a regulated AISP/PISP or an ASPSP?

    First, discuss your complaint directly with the company, institution or bank. If you believe you are not satisfied with their response, you can contact CBB by submitting a Complaint Form available on https://www.cbb.gov.bh/complaint-form/