Bahrain
Bulgaria
Australia
The API specifications are designed to be extensible, allowing for updates to capabilities and functionality.
The Bahrain OBF follows the PSD2‘s guidance. In addition, the Bahrain OBF API specifications have drawn references from the UK OBIE API specification guidelines, the intellectual property rights for which belong to OBIE, UK and are subject to usage limitations as specified by OBIE, the UK.
As the standard is modelled on the Berlin Group’s standard, the XS2A interface is mandatory in the gaining of consent to access account information. Such information may include a transaction history, or a list of accounts.
The TPP must clearly inform the PSU about the rights they are consenting for. The PSU must be strongly authenticated, and then once the TPP has acquired the right for further account information, they must give the PSU information about the result.
If the TPP cannot be identified at the XS2A interface, then the transaction will be rejected.
A set of principles are the basis for the development of the standards for Consumer Data Right. They include:
-
The security of customer data
-
APIs using open standards
-
Simple, informed, and trustworthy data sharing
-
Easily written code should be facilitated by the API standards.
-
Consistency in patterns, structure, security mechanisms and user experience across sectors
-
To be as simple, with as much capability, as possible.
The consumer experience principles put accessibility, use and comprehension of the standards at the fore.
Consent is granted at a point in time and is only as current as the consumer’s original intent.
Buy now, Pay later (BNPL) offers customers a flexible range of instalment options to choose from while shopping. First introduced and revolutionised by Klarna, a Swedish financial firm, in 2005. Recently Taly launched the first Sharia-compliant BNPL service in the Kingdom of Bahrain, which is free for customers.
API Marketplace (rbinternational.com)
Raiffeisen Bank International has included BISTRA standard APIs alongside other European standards in its API Marketplace, a portal for certified Third Parties to use to retrieve key information about Raiffeisen customers’ payment accounts, such as account balance and transaction data, including amounts, dates and counterparties.
Sofia-based Borica Bank has, through its use of the BISTRA standard, built a hub connecting with all Account Servicing Payment Service Providers (ASPSP) on the territory of Bulgaria that have published specialized interface to access their customers’ accounts as required by the PSD2. Upon the customer’s request, the hub may be integrated with other banks outside the territory of Bulgaria.
A compelling case for the development and adoption of data standards and interoperability in the Australian aged care sector (White Paper): White Paper
v1.0.0 / 28 Oct 2020
BISTRA V1.3
V1.21.0 / 22 Mar 2023
Access to account information and payment initiation services requires access to customer accounts through APIs with licensees maintaining customer accounts.
The Bahrain OBF API specifications have drawn references from the UK OBIE API specification guidelines, the intellectual property rights for which belong to OBIE, and are subject to usage limitations as specified by OBIE.
To access the interface, a Third Party Provider (TPP) has to meet the following requirements:
-
Authorization to provide services by by a National Competent Authority under PSD2;
-
Valid PSD2-compliant Qualified Web Authentication Certificate (QWAC) according to (ETSI TS 119 495.2). The certificate must be issued by one of the EU list of trusted providers and must specify the roles for which the provider is authorized:
-
Payment initiation (PSP_PI);
-
Account information (PSP_AI);
-
Issuing of card-based payment instruments (PSP_IC).
-
-
Access to the development or production environment is done by sending an e-mail to support@ccbank.bg with the attached public part of the QWAC. If you would like to have access to the development environment with a test certificate, you also need to provide the certificate chain.
The standards are open source.
The Consumer Data Right confers obligations for users to comply with the standards, and for standards specified as binding standards they apply as under contract between a data holder and an accredited data recipient.
Data holders must meet IT requirements under Consumer Data Right and fulfil information security controls, consent guidelines and API standards, as well as the Consumer Data Right Register design, which defines client registration requirements.
Participants must pass the Conformance Test Suite before they receive an ‘active’ status on the Consumer Data Right Public Register.
Regulated
Regulated
Regulated
The first in the world to include Islamic banking licenses.
The framework is principally based on global ISO standards, specifications and guidelines as published by the Open Banking Implementation Entity (OBIE) in the U.K, the Open Banking standards in Australia, and the Payment Services Directive (PSD2). These have been customized for implementation in Bahrain based on existing practices and terminology used by the Bahrain ecosystem.
Banks must share generic product information relevant to all the principal retail banking products and services, free of any fees or charges.
In addition to these basic services, AISPs/PISPs are free to provide other value-added services for which they may bilaterally agree with the customer. Thus, some accredited third-party providers may decide to charge for some of their products/solutions/services customised for customers’ needs.
As it is formed majorly from the Berlin Group’s standard to conform to the PSD2 regulation, the standard contains stipulations for balance information and creating payments, combined with consent management.
These standards should be used in Australia.
High Level Standards are outlined first, containing components of the standards that are foundational and generally applicable.
The Consumer Experience (CX) Standards contain examples and recommendations for how to implement key rules and standards that relate to the consumer experience.
Non-functional requirements are outlined, including availability and performance requirements as well as traffic thresholds.
The APIs cover Banking, Energy, Telecommunications, Common and Admin specifications.
Commenting is encouraged on the standards.
Banking
Open Banking
-
Account information
-
Payment Initiation
Banking
Open Banking
-
Account information
-
Payment initiation
Banking
Open Data
Open Banking
-
Account information
-
Payment initiation (note: described within transactions, direct debits, and scheduled payments Get Transactions For Account – Consumer Data Standards)
Open Data
-
Energy
-
Telecommunications (Draft)
Current Accounts
Current Accounts
Energy
Lending
Savings
Utilities
Certificates
Registry
Certificates
DCR
Directory
Registry
CIBA
FAPI1
OAuth
OIDC
Access to the Open Banking API is secured using the Open ID Foundation’s Financial Grade API (FAPI) Profile.
Access also requires customers (Payment Service Users or PSUs) to undergo Strong Customer Authentication (SCA) as part of OpenID Connect authorisation flows.
The API currently supports app->web, mobile-web->web, web->web authentication flows.
More about security.
OAuth
FAPI1
OAuth
OIDC
As of September 16th 2022 the information security profile builds upon the foundations of the Financial-grade API Advanced Profile [FAPI-1.0-Advanced] and other standards relating to Open ID Connect 1.0 [OIDC].
For information on the specific normative references that underpin this profile, refer to the Normative References section.
Accounts
Balances
Direct Debits
Other
Parties Or Contacts
Standing Orders
Statements
Transactions
Accounts
Balances
Direct Debits
Parties Or Contacts
Statements
Transactions
Bulk Payments
Future Dated Payments
Single Domestic Payments
Single International Payments
API Specifications
Operational Guidelines
API Specifications
Customer Experience Guidelines
Operational Guidelines
Developer portal Swagger developer sandbox.
Operational
Security Profile
Security Profile
Partial certification process in place
The Central Bank of Bahrain’s (CBB) rules relating to Open Banking were introduced in December 2018, when the CBB mandated the adoption of Open Banking for all retail banks in the Kingdom. While a majority of the banks and the third parties have progressed on implementation of Open Banking to meet the prescribed deadline of June 2019, in order to accelerate adoption, the CBB felt the need to ensure that there is a high degree of consistency in the implementation of Open Banking. Towards this objective, the CBB, in consultation with industry participants, has developed the Bahrain Open Banking framework of standards and guidelines.
In October 2020, the Kingdom launched the Bahrain Open Banking Framework (Bahrain OBF) and the framework is holistic in defining the Open Banking Regulation, guidelines, technical standards for Open API platforms, security standards (including data privacy), and overall governance.
The Second Payment Services Directive (PSD2) was a European legislation that came in to force in January 2016 to regulate electronic payment services and payment service providers throughout the EU. This followed on from the original PSD which was adopted by the EU in 2007.
The PSD2 legislation was to bring APIs into line with the diversity of the banking payment services, online banking functionalities, local regulatory requirements and authentication methods.
On November 26th 2017, the Australian Government introduced Consumer Data Right (CDR) in Australia after years in the making.
The need for ‘data portability’ was contemplated in various reports as early as 2015. Draft legislation was first introduced in 2018, with the Treasury Laws Amendment (Consumer Data Right) Bill 2019 passed in August 2019.
CDR will give consumers greater access to and control over their data and will improve consumers’ ability to compare and switch between products and services.
Governed by the CBB (Central Bank of Bahrain). The board of CBB compromises of seven Directors, appointed by Royal Decree for a renewable term of four years.
The Governor, with a ministerial rank, is in charge of the day-to-day management and is directly accountable to the Board. This position is appointed by Royal Decree for a renewable 5-year term, and it might be supported by Deputy Governors.
The responsibilities of the Governor include presenting a report to the Board within 3 months after the end of the fiscal year regarding operations, audited accounts and external auditor’s opinion on said accounts.
CBB is also required to present financial and operational reports to the Board and the Ministry of Finance.
Internal governance is maintained effectively through a system of internal committees, documented policies, procedures, internal audits and quality assurance functions.
Read more about governance.
The Consumer Data Standards is strictly regulated by the Government with all providers accredited. The Treasurer has appointed CSIRO (The Commonwealth Scientific and Industrial Research Organisation) as the Data Standards Body (DSB) to support the delivery of the Consumer Data Right.
Government organisations involved in establishing the Open Data ecosystem and its governance include the ACCC (Australian Competition and Consumer Commission), which is the lead regulator together with OIAC (Office of the Australian Information Commissioner), CSIRO (Commonwealth Scientific and Industrial Research Organisation), and its subsidiary Data 61, which Consumer Data Standards Team is responsible for developing the standards for CDR (Consumer Data Right), APRA (Australian Prudential Regulation Authority), ASIC (Australian Securities & Investments Commission), the Australian Government Productivity Commission and the Royal Commission into Misconduct in the Banking, Superannuation and Financial Services Industry.
The framework will continue to be revised and updated periodically, based on inputs from the industry and changing global trends.
Data Recipients are expected to design their services to minimise traffic with Data Holders and to be resilient in the case of the rejection of a call by a Data Holder due to traffic threshold breaches.
The service availability requirement for data holders and secondary data holders is 99.5% per month.
Planned outages should be commensurate in length and frequency to other primary digital channels offered by the data holder, published to Data Recipient Software Products with at least one week lead time for normal outages, yet may occur without notification if the change is to resolve a critical service or security issue.
The list of CBB licensees who have provided self-declarations to CBB stating that they have completed their implementation tasks and are fully compliant with Bahrain OBF v.1.0.0 (Phase 1).
All providers must be accredited recipients of data. The Data Availability and Transparency Bill provides for two types of accreditation – Accredited User and Accredited Data Service Provider.
Data holders must submit reports twice a year to the Australian Competition and Consumer Commission (ACCC) and the Office of the Australian Information Commissioner (OAIC).
Users must obtain a license through the CBB.
MIT License
Copyright (c) 2021 Commonwealth of Australia
Law on Payment Services and Payment Systems (LPSPS) and Directive (EU) 2015/2366 (PSD2).
Consumer Data Right (CDR)