BackText onlyPrint

You need the Flash plugin.

Download Macromedia Flash Player



Location: Central Bank of Bahrain Volume 5—Specialised Licensees > Specific Modules (By Type of Licensee) > Type 7: Ancillary Service Providers > Part A > Business Standards > OB Open Banking Module > OB-2 Operating Rules
  • OB-2 Operating Rules

    • OB-2.1 Framework Contracts

      • Legal arrangement and transparency

        • OB-2.1.1

          AISPs and PISPs must establish a framework contract (a legal arrangement) with the customerG . They must also provide the customerG the information set forth below prior to being bound by the framework contract for the services to be provided:

          (a) The following information about the service and the provider:
          i. the name, address and contact details of the PISP or AISP as the case may be;
          ii. a description of the main characteristics of the service to be provided;
          iii. the information or unique identifier that must be provided by the customerG in order for a payment order to be properly initiated or executed;
          (b) the form and procedures for giving consent to provide account information service, the initiation of a payment order and for the withdrawal of consent;
          (c) provisions regarding the time of receipt of a payment order and the cut-off time, if any, established by the licensee and the maximum execution time for the payment services to be provided;
          (d) whether spending limits for the use of a payment instrumentG may be agreed;
          (e) the detail of all fees and charges payable by the customerG to the PISP/AISP, including those connected to the manner in and frequency with which information is provided or made available and, where applicable, a breakdown of the amounts of any charges;
          (f) the means of communication agreed between the parties for the transmission of information or notifications under this Module including, where relevant, any technical requirements for the customerG 's equipment and software for receipt of the information or notifications;
          (g) The terms under which the customerG may opt out from the use of the payment instrumentG ;
          (h) explicit consents required for generic marketing promotions by the PISP/AISP; and
          (i) the terms of the framework contract and information.
          (j) The following information about safeguards and corrective measures:
          i. where relevant, a description of the steps that the customerG is to take in order to keep safe a payment instrumentG and how to notify the PISP/AISP for the purposes of obligations of the customerG in relation to loss, theft, misappropriation, unauthorised use of the payment instrumentsG and personalised security credentials;
          ii. the secure procedures, by which the PISP/AISP will contact the customerG in the event of suspected or actual fraud or security threats;
          iii. the conditions under which the PISP/AISP stops or prevents the use of a payment instrumentG ;
          iv. the customer'sG liability, (payer or payee's liability for unauthorized payment transactions), including details of any limits on such liability;
          v. how and within what period of time the customerG is to notify the licensee maintaining customerG account of any unauthorised or incorrectly initiated or executed payment transaction, and liability, if any for unauthorised payment transactions falling on the licensee maintaining customerG account for execution of unauthorised payment transactions);
          vi. liability, if any, in the event of initiation or execution or non-execution or defective or late execution of payment transactions;
          vii. liability of parties in the event of a cyber-attack and loss of sensitive data; and
          viii. the conditions for any refunds for payment transactions initiated by or through a payee.
          (k) The following information about changes to and termination of the framework contract:
          i. the time given to the customerG to review and accept any proposed changes; which under no circumstances, shall be less than 10 calendar days;
          ii. the proposed terms under which the customerG will be deemed to have accepted changes to the framework contract in accordance, unless they notify the service provider that they do not accept such changes before the proposed date of their entry into force;
          iii. the duration of the framework contract;
          iv. where relevant, the right of the customerG to terminate the framework contract and any agreements relating to.
          (l) The following information about redress:
          i. any contractual clause on the law applicable to the framework contract;
          ii. the availability of alternative dispute resolution procedures for the customerG and the methods for having access to them.
          Added: December 2018

        • OB-2.1.2

          The information specified in Paragraph OB-2.1.1 must be provided to the customerG free of charge before initiation of service.

          Added: December 2018

        • OB-2.1.3

          (a) A framework contract may provide for the PISP to have the right to stop the use of a payment instrumentG on reasonable ground relating to: the security of the payment instrumentG ; or
          (b) the suspected unauthorised or fraudulent use of the payment instrumentG .
          Added: December 2018

        • OB-2.1.4

          AISPs and PISPs must agree the basis, the time period and the manner in which the information on its intention to stop the use of the paymentG instrument will be provided to the customerG and to the relevant licensees maintaining customerG accounts.

          Added: December 2018

    • OB-2.2 Standards for Authentication and Communication

      • Secure authentication

        • OB-2.2.1

          AISPs and PISPs must have in place a strong customerG authentication process and ensure the following:

          (a) no information on any of the elements of the strong customerG authentication can be derived from the disclosure of the authentication code;
          (b) it is not possible to generate a new authentication code based on the knowledge of any other code previously generated; and
          (c) the authentication code cannot be forged.
          Added: December 2018

        • OB-2.2.2

          The CBB will consider application of quantitative thresholds below which the strong customerG authentication requirements may be simplified on a case to case basis.

          Added: December 2018

        • OB-2.2.3

          PISPs and AISPs must adopt security measures that meet the following requirements:

          (a) the authentication code generated must be specific to the payment transaction and the payee agreed to by the payer when initiating the transaction; and
          (b) the authentication code accepted by the licensee maintaining customer accountG corresponds to the original specific amount of the payment transaction and to the payee agreed to by the payer;
          (c) a SMS message must be sent to the customerG upon accessing the online portal or application and when a transaction is initiated and executed;
          (d) any change to the amount or the payee must result in the invalidation of the authentication code generated.
          Added: December 2018

      • Independence of elements of strong authentication

        • OB-2.2.4

          AISPs and PISPs must establish adequate security features for customerG authentication including the use of the following three elements:

          (a) an element categorised as knowledge (something only the user knows), such as length or complexity of the pin or password;
          (b) an element categorised as possession (something only the user possesses) such as algorithm specifications, key length and information entropy, and
          (c) for the devices and software that read, elements categorised as inherence (something the user is), i.e. algorithm specifications, biometric sensor and template protection features.
          Added: December 2018

        • OB-2.2.5

          AISPs and PISPs must ensure that the elements referred to in Paragraph OB-2.2.4 are independent, so that the breach of one does not compromise the reliability of the others, in particular, when any of these elements are used through a multi-purpose device, i.e. a device such as a tablet or a mobile phone which can be used for both giving the instruction to make the payment and for being used in the authentication process. The CBB will consider exempting from a 3 factor authentication on a case to case basis for small value payments provided there are adequate security features.

          Added: December 2018

        • OB-2.2.6

          Where any of the elements of authentication or the authentication code is used through a multi-purpose device including mobile phones and tablets, the AISP and PISP must adopt security measures to mitigate the risk resulting from the multi-purpose device being compromised. The mitigating measures must include each of the following:

          (a) the use of separated secure execution environments through the software installed inside the multi-purpose device; and
          (b) mechanisms to ensure that the software or device has not been altered by the payer or by a third party or mechanisms to mitigate the consequences of such alteration where this has taken place.
          Added: December 2018

      • Confidentiality and Integrity of Personalised Security Credentials

        • OB-2.2.7

          AISPs and PISPs must ensure that the creation of personalised security credentials is performed in a secure environment. AISPs and PISPs must mitigate the risks of unauthorised use of the personalised security credentials and of the authentication devices and software due to their loss, theft or copying before their delivery to the payer.

          Added: December 2018

        • OB-2.2.8

          AISPs and PISPs must ensure the confidentiality and integrity of the personalised security credentials of the customerG , including authentication codes, during all phases of authentication including display and transmission.

          Added: December 2018

        • OB-2.2.9

          For the purpose of Paragraph OB-2.2.8, AISPs and PISPs must ensure that each of the following requirements are met:

          (a) personalised security credentials are masked when displayed and not readable in their full extent when input by the customerG during the authentication;
          (b) personalised security credentials in data format, as well as cryptographic materials related to the encryption of the personalised security credentials are not stored in plaintext;
          (c) secret cryptographic material is protected from unauthorised disclosure.
          Added: December 2018

        • OB-2.2.10

          PISPs and AISPs must ensure that only the customerG is associated with the personalised security credentials, with the authentication devices and the software in a secure manner.

          Added: December 2018

      • Security of Communication Sessions

        • OB-2.2.11

          AISPs and PISPs must ensure that any communication session established with the customerG , and other entities, including merchants, relies on each of the following:

          (a) a unique identifier of the session;
          (b) security mechanisms for the detailed logging of the transaction, including transaction number, timestamps and all relevant transaction data; and
          (c) timestamps which shall be based on a unified time-reference system and which shall be synchronised according to an official time signal.
          Added: December 2018

        • OB-2.2.12

          AISPs and PISPs must rely on qualified certificates for electronic seals for identification of the different parties for communication between parties.

          Added: December 2018

        • OB-2.2.13

          AISPs and PISPs must ensure that the risks against misdirection of communication to unauthorised parties in mobile applications and other customersG ' interfaces offering electronic payment services are effectively mitigated.

          Added: December 2018

        • OB-2.2.14

          AISPs and PISPs must ensure that, when exchanging data via the internet, secure encryption, using strong and widely recognised encryption techniques, is applied between the communicating parties throughout the respective communication session in order to safeguard the confidentiality and the integrity of the data, using strong and widely recognised encryption techniques.

          Added: December 2018

        • OB-2.2.15

          AISPs and PISPs must keep the access sessions offered by the licensee maintaining customerG account, as short as possible and they shall actively terminate the session with the relevant licensee maintaining customer account as soon as the requested action has been completed.

          Added: December 2018

        • OB-2.2.16

          When maintaining parallel network sessions with the bank licensees, AISPs and PISPs must ensure that those sessions are securely linked to relevant sessions established in order to prevent the possibility that any message or information communicated between them could be misrouted.

          Added: December 2018

        • OB-2.2.17

          AISPs and PISPs, with the licensee maintaining customerG accounts must include unambiguous reference to each of the following items:

          (a) the customerG or users and the corresponding communication session in order to distinguish several requests from the same customerG or users;
          (b) for payment initiation services, the uniquely identified payment transaction initiated;
          (c) For confirmation on the availability of funds, the uniquely identified request related to the amount necessary for the execution of transaction.
          Added: December 2018

        • OB-2.2.18

          AISPs and PISPs must ensure that where they communicate personalised security credentials and authentication codes, these are not readable by any staff at any time. In case of loss of confidentiality of personalised security credentials under their sphere of competence, PISPs and AISPs must inform without undue delay the customerG associated with them and the issuer of the personalised security credentials.

          Added: December 2018

        • OB-2.2.19

          AISPs must have in place suitable and effective mechanisms that prevent access to information other than from designated payment accounts and associated payment transactions, in accordance with the customer'sG explicit consent.

          Added: December 2018

        • OB-2.2.20

          PISPs must provide the licensees maintaining customerG accounts with the same information requested from the customerG when initiating the payment transaction directly, unless the collection of additional information for the purposes of the provision of the payment initiation service is agreed otherwise between PISP, payer, and the licensee maintaining customerG accounts.

          Added: December 2018

    • OB-2.3 Payment Transactions

      • Consent to Initiate Payment Transactions

        • OB-2.3.1

          A payment transaction is to be regarded as having been authorised by the payer for the purposes of this Module only if the payer has given its consent to:

          (a) the execution of the payment transaction; or
          (b) the execution of a series of payment transactions of which that payment transaction forms part.
          Added: December 2018

        • OB-2.3.2

          For the purpose of Paragraph OB-2.3.1, such consent must be given in the form, and in accordance with the procedure, agreed between the licensee maintaining the customerG account, the payer and the PISP and may be given via the payee or a PISP.

          Added: December 2018

        • OB-2.3.3

          PISP must ensure that the payer can withdraw its consent to a payment transaction at any time before the point at which the payment order can no longer be revoked under the terms of the framework contract with the customerG .

          Added: December 2018

        • OB-2.3.4

          The customerG may withdraw its consent to the execution of a series of payment transactions at any time with the effect that any future payment transactions are not regarded as authorised for the purposes of this section.

          Added: December 2018

      • Limits on Payment Transactions

        • OB-2.3.5

          The PISP may agree on payment transaction limits based on its own discretion or on account of the following limitations:

          (a) limits imposed by the CBB from time to time;
          (b) limits imposed by any of the licensees; and/or
          (c) limits imposed based on customerG request.
          Added: December 2018

        • OB-2.3.6

          Subject to the framework contract, a PISP has the right to stop the use of a payment instrumentG on reasonable ground relating to:

          (a) the security of the payment instrumentG ; or
          (b) the suspected unauthorised or fraudulent use of the payment instrumentG .
          Added: December 2018

        • OB-2.3.7

          PISPs must ensure that a customerG to whom a payment instrumentG has been issued must keep safe the personalised security credentials and must:

          (a) use it in accordance with the terms and conditions governing such use; and
          (b) notify the PISP in an agreed manner and without undue delay on becoming aware of the loss, theft, misappropriation or unauthorised use of the payment instrumentG .
          Added: December 2018

      • Fees and charges

        • OB-2.3.8

          The AISPs and PISPs may charge fees and charges which reasonably corresponds to the PISP's costs which should be explicitly agreed in the framework contract.

          Added: December 2018

    • OB-2.4 Technology Related Requirements

      • OB-2.4.1

        AISPs and PIPSs must adhere to the best practices of technical standards, including for application program interfaces (APIs), electronic identification, transmission of data and web security. Technology architecture that uses "screen scarping" method must not be used.

        Added: December 2018

      • OB-2.4.2

        AISPs, PISPs in conjunction with licensees maintaining customerG accounts shall develop an open banking API standard based on a standard adopted in a leading financial centre which should be subject to independent tests, including testing in a test environment.

        Added: December 2018

Back to top