A clear and simple explanation of the key terms you will find on this page.
| Expand |
|---|
|
Open Banking is the secure way to give providers access to customer’s financial information. It opens the way to new products and services that could help customers and small to medium-sized businesses get a better deal. It could also give you a more detailed understanding of customer’s accounts, and help customers find new ways to make the most of their money.
Open banking also refers to sharing and leveraging of data (for which customer has consented) by banks with third party developers and firms to build applications and services. For example third party providers (TPPs) provide real-time payments, greater financial transparency options for account holders, marketing and cross-selling opportunities. |
| Expand |
|---|
| title | BOBF (Bahrain’s Open Banking Framework): |
|---|
|
Bahrain’s Open Banking Framework or ‘BOBF’ has been developed considering the relevant use cases (payments as well as account information sharing) that has several business opportunities for the banks and third party providers (TPPs) and caters to the customer’s unique needs in Bahrain. The framework covers both technical as well as non-technical aspects of Open Banking. |
| Expand |
|---|
| title | BOBC (Bahrain’s Open Banking Committee): |
|---|
|
A committee of Industry and Regulatory stakeholders, encompassing a wider set of roles and responsibilities. |
| Expand |
|---|
| title | API (Application Programming Interface): |
|---|
|
An Application Programming Interface or ‘API’ is a set of routines, protocols, and tools for building software applications. An API specifies how software components should interact. |
| Expand |
|---|
| title | ASPSP (Account Servicing Payment Service Provider): |
|---|
|
Account Servicing Payment Service Providers or ‘ASPSP’ refers to CBB licensees who provide and maintain a payment account for a payer and, in the context of the Open Banking Ecosystem are entities that publish Read/Write APIs to permit, with customer consent, payments initiated by third party providers and/or make their customers’ account transaction data available to third party providers via their API end points. |
| Expand |
|---|
| title | TPP (Third Party Provider): |
|---|
|
Third Party Providers or “TPP” are CBB licensees that use APIs developed to Standards to access customer’s accounts, in order to provide account information services and/or to initiate payments.
Third Party Providers are either Payment Initiation Service Providers (PISPs) or Account Information Service Providers (AISPs) or both Payment Initiation Service Providers (PISPs) and Account Information Service Providers (AISPs). |
| Expand |
|---|
| title | PISP (Payment Initiation Service Provider): |
|---|
|
Payment Initiation Service Provider or ‘PISP’ refers to a person licensed by the CBB to initiate payment or credit transfers for the customer from an account held with a licensed bank, financing company or PSP. The role of a PISP is restricted to providing the technology or other means in order to initiate a payment order and the handling of communication or electronic documents between the customer and the licensees should the terms of the offer include such services. PISPs must not receive or otherwise handle customer funds in the course of providing payment initiation services. |
| Expand |
|---|
| title | AISP (Account Information Services Provider): |
|---|
|
Account Information Services Provider or ‘AISP’ refers to a person licensed by the CBB to provide account information services using an online portal, mobile or smart phone application, device or other electronic media which a consenting customer can use to obtain aggregate or consolidated information about his account balances with licensed banks, financing companies and other licensees. The role of an AISP is restricted to providing the technology or other means in order to provide account information to the customer and the handling of communication or electronic documents between the customer and the licensees should the terms of the offer include such services. AISPs must not receive or otherwise handle customer funds in the course of providing account information services. |
| Expand |
|---|
|
A natural or legal person (end-user) making use of a payment service as a payee, payer or both. A natural or legal person (end-user) making use of an account information service as part of a consent driven data sharing arrangement. |
| Expand |
|---|
| title | SCA (Strong Customer Authentication): |
|---|
|
Strong Customer Authentication or ‘SCA’ is an 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, a particular cell phone and number]) and inherence (something the user is [or has, for example, a finger print 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. |
| Expand |
|---|
| title | PDPL (Personal Data Protection Law): |
|---|
|
The PDPL is the data protection law of Bahrain that applies to any entity processing personal data wholly or partly by automated means – as well as the manual processing of personal data as part of an organized filing system. |
| Expand |
|---|
| title | PSD2 (Revised Payment Services Directive): |
|---|
|
The Payment Services Directive 2015/2366, as amended or updated from time to time and including the associated Regulatory Technical Standards developed by the EBA and agreed by the European Commission and as implemented by the PSR and including any formal guidance issued by a Competent Authority. |
| Expand |
|---|
|
This is an absolute requirement of this document. |
| Expand |
|---|
|
This is an absolute prohibition of this document. |
| Expand |
|---|
|
There may exist valid reasons to ignore a particular point in this document, but the full implications need to be understood before choosing a different course. |
| Expand |
|---|
|
There may exist valid reasons when the particular point is acceptable or even useful, but the full implications need to be understood before implementing any point described with this label. |
| Expand |
|---|
|
This is an informed suggestion but that the point is optional. |
| Expand |
|---|
|
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: For fields An 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.
|
| Expand |
|---|
|
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: For fields: All fields that are not marked as Mandatory are Conditional. An 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. |
| Expand |
|---|
|
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: For fields: For any endpoints which are implemented by an ASPSP, the fields are either Mandatory or Conditional. |
...