FAQs

 

1. General

What is Bahrain Open Banking Framework (Bahrain OBF)?

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.

What are the guiding principles for the Bahrain Open Banking Framework (Bahrain OBF)?

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

How is the Bahrain OBF different from the CBB Rulebook?

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.

How can I view the latest version of Bahrain OBF?

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.

What will happen to the existing laws on data privacy, namely Personal Data Protection Law (PDPL)? Will my data continue to be governed by PDPL?

Any Open Banking participant supplying or accessing data has obligations under existing legal and regulatory frameworks in Bahrain, and as such, shall comply with PDPL, CBB Law and the CBB Rulebook. Guidelines drafted under Bahrain OBF are complementary to and not a replacement of any existing legal or regulatory requirements in Bahrain.
All CBB licensees and their technology providers, if any, 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.

As a user/customer, do I have to pay any additional charge for using Open Banking services?

No, there is no additional charge for using Open Banking as a service. Keeping in view the overall objectives of Open Banking which include enhancing customer experience and competitiveness, banks must share generic product information relevant to all the principal retail banking products and services, free of any fees or charges.
In addition to these basic services, AISPs/PISPs are free to provide other value added services for which they may bilaterally agree with the customer. Thus, some accredited third party providers may decide to charge you for some of their products/solutions/services customized for your needs.

Can I use Open Banking without enabling online banking services?

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

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

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.

What access rights do AISPs/PISPs have?

Under Bahrain OBF, with explicit consent from customers, the 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).

2. Security and Privacy

Is Bahrain Open Banking safe?

Safety and Security of user/customer data have 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.

Will I enroll automatically for Open Banking services?

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

Will I be informed about the end use of my data by a third party?

Yes. You need to give 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. Further, only licensed AISPs/PISPs are allowed to collect, access and use customer data for the purpose for which it was collected in accordance with Bahrain OBF guidelines.

How can I revoke access to AISPs/PISPs who use my data?

Access to data is driven by consent and the purpose for which access was granted in the 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.

What happens to my data after I cancel access?

  • Post Customer revocation (revoke on-going consents that they have given to that AISP) or on completion of approved customer consent period or when purpose for use of data is complete, AISPs must stop using the customer data and any copies/references for any activities. 

  • Any anonymized and aggregated data, which cannot be associated to an identifiable user/customer can continue to be stored for archiving, audit, historical, or statistical purposes.

  • Storing of customer data and complete transaction records post customer revocation for archival purposes should be in line with existing legal/regulatory requirements (for audits etc.)

Can a PISP make a payment from my account without my authorisation?

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

What if a payment is made from my account without my 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.

What can I do if my data has been used incorrectly or has been misused?

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

How will Open Banking disputes be managed?

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.

What policies should be in place to archive data?

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

How can I complain about a regulated AISP/PISP or an ASPSP?

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/

What is strong customer authentication?

Strong Customer Authentication or ‘SCA’ is authentication based on the use of three elements categorized as knowledge (something only the user knows [for example, a password]), possession (something only the user possesses [for example, particular cell phone and number]) and inherence (something the user is [or has, for example, a fingerprint or iris pattern]) that are independent, so the breach of one does not compromise the others, and is designed in such a way as to protect the confidentiality of the authentication data. For further information on elements of SCA or related exemptions, kindly refer to relevant Open Banking sections of the Rulebook.

What are the type of Authentication methods supported in Open banking?

The Bahrain OBF will support both redirection and decoupled authentication to allow a user/customer to use the same authentication mechanisms while using an AISP or PISP as they use when accessing the ASPSP directly. With either flow, all OB participants must adhere to the customer experience specifications listed as part of Bahrain OBF. (Additional details on how the flow works is provided on the OB user journeys page. Link for the same will be provided as part of the response).
The experience provided to the user/customer during the OB journey should, at minimum, be equivalent to the journey with their ASPSP online channel (principle of equal parity).
Redirection can include scenarios such as Browser based, APP based, browser to APP, APP to browser, etc. based on whether the user/customer has an ASPSP/AISP/PISP app and the device compatible with the app. Similarly, decoupled based authentication, has multiple scenarios including using dynamic identifier, static identifiers, etc. based on the business.

With the objective of ensuring seamless customer journey, it is recommended that the Open Banking participants (ASPSPs, AISPs and PISPs) consider adopting the authentication methods based on level of safety, overall user experience, adherence to Bahrain OBF standards, readiness and current usage in the banking system.

3. Accreditation

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

What are the criteria for accreditation?

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

How 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 provider should clearly state their accreditation status.

What happens when an accredited entity does not comply with the Open Banking regulations?

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

4. API Specification

What is the use of Unique Identifiers (Id Fields)?

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.

Are ASPSPs allowed to create their own enumeration when required?

Yes, ASPSPs can create their own enumerations. The Bahrain OBF Specification includes various fields of Enumerated data types, where either the values are fixed to the defined set of alternatives (i.e. Static Enumerations), or flexible with defined set of alternatives, and ASPSPs can use/extend these alternatives (i.e. Namespaced Enumerations). When extending a namespaced enumeration:

ASPSPs must not publish an ASPSP-specific enumerated value if the existing Bahrain OBF guidelines defines the enumerated value.
ASPSPs must place such values in a namespace consisting of their two-letter country code (ISO 3166-1 Alpha-2 code), followed by a full-stop, followed by their name. e.g. BH.Bank1.enum1, where Bank1 is the bank name and enum1 is the extended enumeration.

What are the date formats used in the API?

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

2020-10-05T10:43:07+03:00

2020-10-03T14:43:41Z

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 time zone. For example:

2020-10-05T10:43:07

2020-10-05

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

Tue, 10 Oct 2020 19:43:31 GMT+03:00

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.

//Wed, 12 Oct 2020 14:45:00 GMT+03:00

1581507900

 What will be the structure of resource URI path?

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

What are request headers?

Request Header is a HTTP header that contains information about the fetched request by the client. 

Header Value

Notes

POST Requests

GET Requests

DELETE Requests

PUT

Requests

PATCH
Requests

x-fapi-auth-date

The time when the User/Customer last logged in with the AISP/PISP. e.g., x-fapi-auth-date: Mon, 11 October 2020 19:43:31 GMT+03:00.

Optional

Optional

Optional

Do not use

Optional

x-fapi-customer-ip-address

The User’s/Customer’s IP address if the User/Customer is currently logged in with the AISP/PISP.

Optional

Optional

Optional

Do not use

Optional

x-fapi-interaction-id

An RFC4122 UID used as a correlation Id.
If provided, the ASPSP must "play back" this value in the x-fapi-interaction-id response header.

Optional

Optional

Optional

Optional

Optional

Authorisation

Standard HTTP Header; Allows Credentials to be provided to the Authorisation / Resource Server depending on the type of resource being requested. For OAuth 2.0 / OIDC, this comprises of either the Basic / Bearer Authentication Schemes.

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Content-Type

Standard HTTP Header; Represents the format of the payload being provided in the request.
This must be set to application/json, except for the endpoints that support Content-Type other than application/json (e.g POST /file-payment-consents/{ConsentId}/file), the ASPSP must specify the available options on their developer portals.
This must be set to application/jose+jwe for encrypted requests.
The AISP/PISP may provide additional information (e.g. a 'q' value and charset).

Mandatory

Do not use

Do not use

Mandatory

Mandatory

Accept

Standard HTTP Header; Determine the Content-Type that is required from the Server.
If the AISP/PISP expects an unencrypted response, it must indicate that the only a JSON response is accepted (e.g. by setting the value to application/json) as a content header for all endpoints that respond with JSON.
If the AISP/PISP expects an encrypted response, it must indicate that the only a JWT response is accepted (e.g. by setting the value to application/jose+jwe) as a content header for all endpoints that respond with JSON.
For endpoints that do not respond with JSON (e.g. GET ../statements/{StatementId}/file), the ASPSP must specify the available options on their developer portals.
If set to an unacceptable value the ASPSP must respond with a 406 (Not Acceptable).
If not specified, the default is application/json.

Optional

Optional

Do not use

Optional

Optional

x-idempotency-key

Custom HTTP Header; Unique request identifier to support idempotency.
Mandatory for POST requests to idempotent resource end-points.
Must not be specified for other requests.

Optional

Do not use

Do not use

Do not use

Do not use

x-jws-signature

Header containing a detached JWS signature of the body of the payload.
Refer to resource specific documentation on when this header must be specified.

API specific

API specific

API specific

Mandatory

API specific

x-customer-user-agent

The header indicates the user-agent that the User/Customer is using.
The AISP/PISP may populate this field with the user-agent indicated by the User/Customer.
If the User/Customer is using an AISP/PISP mobile app, the AISP/PISP must ensure that the user-agent string is different from browser based user-agent strings.

Optional

Optional

Optional

Optional

Optional

What are response headers?

Response Header is a HTTP header that contains the responses to inbound HTTP requests.

Header Value

Notes

Mandatory

Content-Type

Standard HTTP Header; Represents the format of the payload returned in the response.
The ASPSP must return Content-Type: application/json as a content header for all unencrypted endpoints, except the GET ../statements/{StatementId}/file and ../file-payment-consents/{ConsentId}/file endpoints, where it is up to the ASPSP to specify available options.
The ASPSP must return Content-type: application/jwe for all encrypted end-points.

Mandatory

x-jws-signature

Header containing a detached JWS signature of the body of the payload.
Refer to resource specific documentation on when this header must be returned. Where a signed response is indicated in the documentation this header should be returned for error responses where a response body is returned.

API specific

x-fapi-interaction-id

An RFC4122 UID used as a correlation Id.
The ASPSP must set the response header x-fapi-interaction-id to the value received from the corresponding fapi client request header or to a RFC4122 UUID value if the request header was not provided to track the interaction. The header must be returned for both successful and error responses.

Mandatory

Retry-After

Header indicating the time (in seconds) that the AISP/PISP should wait before retrying an operation.
The ASPSP should include this header along with responses with the HTTP status code of 429 (Too Many Requests).

Optional

Does GET operation support filtering?

An ASPSP must provide limited support of filtering on GET operation 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.

Does GET operation support pagination?

An ASPSP MAY provide a paginated response for GET operation 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.

What will be the error flow if the access token is missing or has expired?

The error 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.

What will be the error flow if the access token scope is missing or invalid?

The error 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.

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

The error 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.

What will be the error flow if there is sudden burst of API requests?

The error 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.

The error 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 Authorisation Code being generated.

5. Further Information

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

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

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

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

 

CENTRAL BANK OF BAHRAIN © 2020