Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

1. Glossary

A clear explanation is provided below for the terms used across this document

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

  2. 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)

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

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

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

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

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

  8. Must/Required: This is an absolute requirement of this document

  9. Must not: This is an absolute prohibition of this document

  10. May: This is an informed suggestion but that the point is optional 

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

The CBB’s rule books and the Personal Data Protection Law (PDPL) provide direction on multiple internal security controls, processes and rules for adherence by ASPSPs (Banks) and AISP/PISPs. The objective of this document is to provide additional guidance and best practices on leveraging globally accepted and widely adopted security standards to help create a more robust/secure open banking ecosystem in Bahrain.  

All requirements and best practices stated in this document are in addition to existing rules and guidelines set by the CBB and the PDPL. In all cases, external assurance and certification of the Information Security adherence is preferable to self-certification. 

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. 

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

In order to protect the confidentiality, integrity and availability of information and data in the open banking ecosystem, all participants should ensure that security is given sufficient profile and influence in their organisation. Recommended areas of security capability include (but are not limited to): 

  • Specialist Information Security function

  • Security Operations Centre (SOC)

  • IT systems controls around the infrastructure and applications

  • Penetration testing

  • Cybersecurity function (strategy, policy, governance)

  • Counter fraud function and reporting of threat

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

3.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: 

  • Accurately evaluate organisational ability to defend against attack

  • Obtain detailed information on actual, exploitable security threats

  • Intelligently prioritise remediation activity, apply necessary security patches and allocate security resources 

All systems and infrastructure should be regularly tested for vulnerabilities by an external penetration testing expert. It is recommended that such an expert is professionally accredited. 

Penetration testing for all ASPSP (Banks), AISPs and PISPs must be conducted by external experts every six months (at minimum) as per the rules laid out in the existing security and open banking rules issued by the CBB in Volume 1 and Volume 5 of the rule book. 

Further, penetration testing may be additionally conducted by AISPs/PISPs/ASPSPs based on the open banking release cycle, i.e. every time a major release has been made, and any minor release that may potentially directly impact/expose any sensitive or personal data of users/customers. 

Major and minor releases have been defined in the Open Banking Operational Guidelines 

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

OpenID Foundation, a non-profit international standardisation organisation of individuals and companies committed to enabling, promoting and protecting OpenID technologies, is working to ensure that the profile is maintained as a world-class security standard which provides the very best protection available for all users/customers. 

The section covers Open Banking security aspects of the API specification, including:

  • Authentication and Authorisation

  • Data Encryption

  • Fraud detection and monitoring

 4.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:

  • Data attribute providers or ASPSPs should retain control over authentication method

  • OAuth 2.0 in conjunction with OpenID Connect are recommended as authentication and authorisation protocols of choice

Once a User/Customer has authenticated with their data attribute provider, tokens should be used to ensure the third party is acting within the bounds of the permissions granted. The third-party service should provide evidence that it is entitled to use the authorisation token (e.g. by way of providing a client ID and client secret) to the data attribute provider.

Each data attribute provider will be responsible for issuing its own tokens and ensuring third parties are in possession of legitimate tokens. 

OAuth 2.0:

  • The OAuth 2.0 authorisation framework enables a third-party application to obtain limited access (i.e. set scope) to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its behalf. This specification replaces and obsoletes the OAuth 1.0 protocol

  • OAuth 2.0 provides delegated authorisation workflows for diverse applications such as web applications, desktop applications, mobile phones and home automation devices while providing a simple platform for developers to harness

  • In an OAuth based authorisation, a consumer requests access to resources under the control of a resource owner. For accessing these resources, the consumer is provided a different set of credentials.

  • This can be used for accessing the APIs from multiple devices including mobile apps, desktops etc.

  • This can be modified to include any unique national ID as the access token against which an individual or an organisation can be authenticated

  • Further details on the OAuth 2.0 specifications can be found on their website

OpenID Connect (OIDC):

  • OpenID Connect (OIDC) is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It uses straightforward REST/JSON message flows with a design goal of simplifying things and works over the existing HTTP standard

  • OpenID Connect enables developers to create an authentication mechanism across websites and applications without creating a separate username/ password file combination of their own

  • OpenID has the capability to manage multiple types of clients including browser based JavaScript and native mobile applications. Apps designed using OpenID are able to utilise sign-in workflows and receive confirmable assertions about the identity of the user. (Identity, Authentication + OAuth 2.0 = OpenID Connect)

  • This can be used for accessing the APIs from multiple devices including mobile apps, desktops etc. in a manner similar to how Google/Facebook single sign on works across other websites. This can be modified to include the UID as the access token against which an individual or an organisation can be authenticated

  • Further details on the OIDC specifications can be found on their website

User/Customer consent for authorisation:

  • In the context of data-sharing with a third-party, a principle of informed consent should be adopted. The user should clearly understand the authorisation they are being asked to provide, including:

    • Who they are providing authorisation to

    • What they are providing authorisation for (i.e. what the authorisation will permit the third party to do)

    • How long the authorisation will last for

To ensure accurate adoption OAuth 2.0 and OpenID Connect (OIDC) frameworks while developing new API profiles, ASPSPs (Banks) and AISP/PISPs could leverage security structures and rules set by the OpenID Foundation’s (OIDF) Financial-grade API (FAPI) profile. The Financial-grade API security profile can be applied to online services in any market area that requires a higher level of security than provided by standard OAuth or OpenID Connect. The CBB’s use case API specifications are built keeping the FAPI and OAuth 2.0 principles in mind.

The OIDF Financial-grade API (FAPI) is a REST API that provides JSON data representing higher risk data. These APIs are protected by the OAuth 2.0 Authorization Framework and other specifications. This profile describes security provisions for the server and client that are appropriate for Financial-grade APIs. Additional information on the FAPI profile is available on the OIDF website and on the links below:

Part 1: Read-Only API Security Profile

Part 2: Read and Write API Security Profile 

4.2 Data encryption

API connections and data in transit should be encrypted to ensure that all data in transit is safe and secure.

API connections and data in transit must be encrypted using TLS v1.2 as a minimum, with a defined set of strong cipher suites.

Transport Layer Security (TLS) v 1.2

  • TLS was designed with the goal of providing privacy and ensuring data integrity between two communicating applications.

  • This has two layers:

    • The first layer uses TLS Record Protocol to encapsulate other higher level protocols.

    • The second layer uses the TLS Handshake Protocol which allows the server and client to authenticate each other. The protocol allows negotiation and agreement of a cryptographic algorithm and keys prior to transmission or receipt of any data.

  • This is a basic level of security which rides on the TCP protocol and HTTPS. All RESTful APIs by default are created to use this as an encryption mechanism.

In order to achieve full FAPI compliance, all open banking stakeholders may run an additional layer of AES 128/256-bit encryption of signatures.

The OBC and Industry stakeholders may also further consider non-repudiation of messages using digital signatures, and explore the usage and adoption of streaming APIs for reading data especially for AISP related use cases.

Further inputs of the OBC and industry discussions may be submitted to the CBB for further considerations to changes to the security guidelines 

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

  • The API must provide support for out-of-band (OOB*) authentication

    • Out-of-band (OOB): Out-of-band is activity outside a defined telecommunications frequency band, or, metaphorically, outside some other kind of activity

  • ASPSPs must notify the User/Customer asynchronously/OOB when significant actions have occurred (e.g. a change to a payee)

  • The ASPSP API response should inform the third party that an OOB process is underway so that, where appropriate, they can inform the User/Customer

  • Inclusion of fraud-relevant information (e.g. IP addresses) in the API return message from the third party

  • No labels