| Table of Contents | ||||
|---|---|---|---|---|
|
1.
...
A clear explanation is provided below for the terms used across this document
API: An Application Programming Interface (API) is a set of routines, protocols, and tools for building software applications. An API specifies how software components should interact
ASPSP: Account Servicing Payment Service Providers (ASPSP) refers to the CBB licensees (include conventional retail bank licensees, Islamic retail bank licensees financing companies and PSPs operating electronic wallets) who provide and maintain a payment account for a User/Customer 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. CBB licensees here refer to all entities maintaining customer accounts as defined in the Open Banking Module (Volume 5 of CBB Rulebook, Section OB-B.1)
PISP: Payment Initiation Service Provider (PISP) refers to a person licensed by the CBB to initiate payment or credit transfers for the customer from an account held with an ASPSP. 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
AISP: Account Information Services Provider (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/her account balances with ASPSP. 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.
User/Customer: 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
Should/Recommended: 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
Should Not: 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
Must/Required: This is an absolute requirement of this document
Must not: This is an absolute prohibition of this document
May: This is an informed suggestion but that the point is optional
...
Overview
The Central Bank of Bahrain (CBB) has worked with experts to develop rigorous security specifications for the wider Open Banking ecosystem. This document covers the key considerations of security that would be essential from an Open Banking ecosystem and applicable to ASPSPs (Banks) and AISP/PISPs.
...
This document has drawn references from the ISO 27001:2013 standard, Open Banking Standard published by the Open Banking Implementation Entity (OBIE) in the UK, the Open ID Foundation’s API profiles, CBB Rulebook in Bahrain and the Review into Open Banking publication in Australia. It also incorporates key stakeholder inputs in the Bahrain market.
...
2. Open Banking System Security Guidelines
CBB recommends all stakeholders in the open banking ecosystem must align to ISO27001: 2013 standard. Further, all ASPSPs/AISPs/PISPs should leverage a risk based approach to security by leveraging internationally recognized “National Institute of Standards and Technology”-NIST framework.
...
All ecosystem participants (ASPSP/AISP/PISP) must ensure compliance with existing guidelines published by the CBB on cyber risk, cyber and internet security (CBB Rule Book Volume 1 and Volume 5).
...
2.1 Penetration Testing
Penetration testing systematically probes for vulnerabilities in applications and networks and should be undertaken in a controlled manner (to minimise any impact on live operations). The benefits of penetration testing include:
...
Major and minor releases have been defined in the Open Banking Operational Guidelines
...
3. Open Banking API security specifications
All participants must implement the Open Banking security aspects of the API specification, including authentication, authorisation, access levels and permission and encryption. The following API security specifications leverage the OpenID foundation’s financial API (FAPI) read and write API security profile. This specification is published on the OpenID Foundation website at openid.net.
...
Authentication and Authorisation
Data Encryption
Fraud detection and monitoring
...
3.1 Authentication and Authorisation
The process through which a User/Customer authenticates itself to its data attribute provider or ASPSP (in order to further authorise a third party access) will be a tripartite process and should be designed to minimise digital friction. Specifically:
...
Part 2: Read and Write API Security Profile
...
3.2 Data encryption
API connections and data in transit should be encrypted to ensure that all data in transit is safe and secure.
...
Further inputs of the OBC and industry discussions may be submitted to the CBB for further considerations to changes to the security guidelines
...
3.3 Fraud detection and monitoring
In addition to the counter fraud function, all participants must include completed risk indicators within their payload to facilitate strong security across the open banking ecosystem and aid fraud detection and prevention.
...