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

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.

The APIs require TLS 1.2 Mutual Authentication and this may be used as a means of non-repudiation. However, it would be difficult to maintain digital records and evidence of non-repudiation if the API only relied on TLS 1.2.

A solution for non-repudiation that does not rely on TLS, would be achieved by providing a JWS with detached content (as defined in RFC 7515 - Appendix F) in the HTTP header of each API request.

The HTTP body would form an un-encoded payload as defined in RFC 7797.

The JWS would be signed using an algorithm that supports asymmetric keys.

A request would be signed by a AISP/PISP's private key and a response would be signed by the ASPSP's private key.

Not all API requests and responses are signed. Whether message signing is mandatory, supported or not supported is documented along with each API.

Message encryption is implemented through JSON Web Encryption (JWE).

The approach differs from message signing in that:

• The entire request or response payload is delivered in the form of an encrypted JWT.

• The definition of a given request or response in the Swagger specification represents the decrypted payload.

• The JWE will not be represented in its encrypted form in the Swagger specifications.

• Sending or expecting to receive an encrypted payload is denoted by setting the Accept or Content-type header to application/jose+jwe.

If an ASPSP does not support message encryption then should reject any requests with a Content-type or Accept headers that indicate that message encryption is required.

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.

The functionality, endpoints and fields within each resource are categorised as 'Mandatory', 'Conditional' or 'Optional'.

Mandatory

Functionality, endpoints and fields marked as Mandatory are required in all cases for regulatory compliance and/or for the API to function and deliver essential customer outcomes.

For functionalities and endpoints:

• An ASPSP must implement an endpoint that is marked Mandatory.

• An ASPSP must implement functionality that is marked Mandatory.

For fields:

• A AISP/PISP must specify the value of a Mandatory field.

• An ASPSP must process a Mandatory field when provided by the AISP/PISP in an API request.

• An ASPSP must include meaningful values for Mandatory fields in an API response.

Conditional

Functionality, endpoints and fields marked as Conditional may be required in some cases for regulatory compliance (for example, if these are made available to the USER/CUSTOMER in the ASPSP's existing Online Channel, or if ASPSPs (or a subset of ASPSPs) have been mandated by a regulatory requirement).

For functionalities and endpoints:

• An ASPSP must implement functionality and endpoints marked as Conditional if these are required for regulatory compliance.

For fields:

• All fields that are not marked as Mandatory are Conditional.

• A AISP/PISP may specify the value of a Conditional field.

• An ASPSP must process a Conditional field when provided by the AISP/PISP in an API request, and must respond with an error if it cannot support a particular value of a Conditional field.

An ASPSP must include meaningful values for Conditional fields in an API response if these are required for regulatory compliance.

Optional

Functionality and endpoints marked as Optional are not necessarily required for regulatory compliance but may be implemented to enable desired customer outcomes.

For functionalities and endpoints:

• An ASPSP may implement an Optional endpoint.

• An ASPSP may implement Optional functionality.

For fields:

• There are no Optional fields.

For any endpoints which are implemented by an ASPSP, the fields are either Mandatory or Conditional.

The API requests and responses must use a UTF-8 character encoding. This is the default character encoding for JSON (RFC 7158 - https://tools.ietf.org/html/rfc7158#section-8.1)

However, an ASPSP's downstream system may not accept some UTF-8 characters, such as emoji characters (e.g. "J" may not be an acceptable Payment Reference). If the ASPSP rejects the message with a UTF-8 character that cannot be processed, the ASPSP must respond with an HTTP 400 (Bad Request) status code.

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