1. Overview
The Operational Guidelines set out criteria, guidance and requirements for Account Servicing Payment Service Providers (“ASPSPs”) to deliver an effective Open Banking ecosystem and meet the needs of Account Information Service Providers (“AISPs”) and Payment Initiation Service Providers (“PISPs”) in providing services to users/customers.
These guidelines provide recommended benchmarks to support ASPSPs in complying with Open Banking guidelines and help regulators track availability and performance of data generating APIs. On adoption of the Operational Guidelines, ASPSPs will be in a better position to successfully demonstrate the availability and performance of APIs and their active interactions with AISPs and PISPs in the market.
This document has drawn references from the CBB Rulebook in Bahrain, the Open Banking Standard published by the Open Banking Implementation Entity (OBIE) in the U.K., the Payment Services Directive (PSD2) and Regulatory Technical Standards (RTS) in European Union and the Review into Open Banking publication in Australia. It also incorporates key stakeholder inputs in the Bahrain market. This document will be updated periodically based on inputs from the market.
The Operational Guidelines have the following objectives:
To provide clarity to ASPSPs to enable them to design effective and high-performing dedicated interfaces while fulfilling their regulatory obligations
To ensure that AISPs and PISPs have access to consistently well-designed, well-functioning and high performing dedicated interfaces
To provide the CBB with insights into the availability and performance of key ecosystem APIs and identify issues which may impact adoption and experience
In addition, adherence to these Operational Guidelines will provide the following benefits:
Improve efficiencies: Minimize the potential impact to a business when systems or supporting networks are down (including instances where they have not been tested appropriately)
Reduced Reputational Risk: Protect the reputation of ASPSPs/AISPs/PISPs and the Open Banking ecosystem as a whole
2. Availability and Performance
This chapter outlines various API availability and performance requirements and recommendations for ASPSPs in Bahrain. AISPs and PISPs are dependent on the well-established interfaces provided by ASPSPs so that they can in turn provide reliable services to their users/customers.
2.1 Key Indicators for Availability and Performance
The following tables set out, for each requirement:
Guidelines to explain how these should be calculated by ASPSPs for the dedicated interface
A recommended benchmark for the dedicated interface on the basis of global best practices
ASPSPs should ensure that the APIs/dedicated interfaces offered to AISPs/PISPs should at all times have the same level of availability and performance as the interfaces made available to the users/customers via the ASPSPs online environment.
For an effective Open Banking ecosystem to thrive, there is a need for industry-wide benchmarks, referred to as the "Recommended Benchmarks". Since these guidelines are based on global best practices, these will be reviewed on a regular basis in consultation with industry stakeholders. ASPSPs should aim to adhere to the Recommended Benchmarks for their interfaces as a best practice.
Additionally, the guiding principle of these benchmarks is that ASPSPs must ensure (at least) parity between the availability and performance of the best performing interface (that they own and maintain to interact directly with customers) and that of their open banking interface which may be leveraged by AISP/PISPs.
2.1.1 Availability
The definition of a period of availability is a period of time when any of the API end points defined in the Bahrain Open Banking Framework (BOBF) are able to reliably provide a successful response to an appropriately constructed request.
AISPs/PISPs may consider that an API is only available if it is responding to all valid AISP/PISP requests:
Without error messages and
That have received a successful response from the ASPSP, for example returning the data required to be provided to AISPs
This section sets out a minimum of two KPIs for availability that an ASPSP should have in place for each API. The following table explains these KPIs in detail and provides guidance on how they should be calculated.
Table 1 – Key Indicators for Availability
Title | Requirement | Calculation Guidelines | Recommended Benchmark |
|---|---|---|---|
The uptime per day of all interfaces | For the purpose of calculating the availability indicators, the ASPSP should: a) calculate the percentage uptime as 100% minus the percentage downtime | For each 24 hour period, uptime is calculated as 100% minus the total percentage downtime in that period. | A quarterly uptime of 99.5%[1] |
The downtime per day of all interfaces | For the purpose of calculating the availability indicators, the ASPSP should: a) calculate the percentage downtime using the total number of seconds the API was down in a 24 hour period, starting and ending at midnight
b) count the interface as ‘down’ when five consecutive requests for access to information for the provision of payment initiation services, account information services are not replied to within a total timeframe of 30 seconds, irrespective of whether these requests originate from one or multiple PISPs/AISPs. In such a case, the ASPSP should calculate downtime from the moment it has received the first request in the series of five consecutive requests that were not replied to within 30 seconds, provided that there is no successful request in between those five requests to which a reply has been provided | Downtime should be calculated as follows:
At a minimum, downtime should be measured if:
This should include any vendor/supplier failures in the case where the ASPSP has contracted the vendor/supplier to deliver a related service However, this should exclude errors resulting from issues outside of the ASPSP's direct control, such as issues with AISP/PISP software, infrastructure or connectivity. | A quarterly downtime of 0.5%. (approx. 11 hours per quarter, or just under four hours per month, to allow for planned releases, updates, and also any unplanned downtime) |
[1] This is the benchmark for Business as usual/normal conditions and not in cases of force majeure events such as natural calamities, war, cyber threats etc.
2.1.2 Performance
The BOBF defines a number of endpoints which should be made available by ASPSPs. The Performance of API end points should be measured in response time of individual API requests from receipt of request to delivery of response. While all supported endpoints should be included by ASPSPs when calculating error rates, for reporting response times the consent endpoints should be ignored, as these are not considered part of the process of 'providing the information requested' to the AISP/ PISP for account information or payment initiation.
This section sets out a minimum of four KPIs for performance that an ASPSP should have in place for each of its API. The following table explains these KPIs in detail and provides guidance on how they should be calculated.
Title | Requirement | Calculation Guidelines | Recommended Benchmark |
|---|---|---|---|
PISP response time | For the purpose of calculating the performance indicators, the ASPSP should: a) calculate the daily average time (in milliseconds) taken, per request, for the ASPSP to PISP with all the information requested | The "time taken per request" should be calculated for each day using the mean value of Time to Last Byte (TTLB) measured in milliseconds, starting from the time that each endpoint request has been fully received by the ASPSP and stopping when the last byte of the response message has been transmitted to the PISP. The following API endpoints should be included when calculating PISP response times, for each endpoint supported by the ASPSP:
The ASPSPs signed response to the POST will inherently act as proof of receipt of the payment order by the ASPSP, which will enable the PISP to log a reference and the date of this receipt. Both the POST and the GET endpoints contain all information relating to the payment, which, depending on the payment type, should include reference, amount, exchange rate, charges, and status (which may change between POST and any subsequent GET). The POST endpoints above cater for the ASPSP to make the information available to the PISP immediately after receipt of the payment order, and the provision of all information on the initiation of the payment transaction and all information accessible to the ASPSP regarding the execution of the payment transaction. The GET endpoints cater for the ASPSP to provide confirmation to the PISP that payment initiation has been successful, in order to enable the PISP to provide this information to the user/customer. Since different endpoints will have different payload sizes for request and response (especially relevant for bulk/batch payment endpoints involving large files), and in order to facilitate a 'like for like' comparison with user/customer interfaces, ASPSPs should report on the average time per megabyte (MB). This can be calculated by dividing the total response time in milliseconds by the total payload response size in MB, across all API calls for all API endpoints for each day. | An average TTLB of 750 milliseconds per response for all but bulk/batch payments |
AISP response time | For the purpose of calculating the performance indicators, the ASPSP should: a) calculate the daily average time (in milliseconds) taken, per request, for the ASPSP to provide the AISP with all the information requested | The "time taken per request" should be calculated for each day using the mean value of Time to Last Byte (TTLB) measured in milliseconds, starting from the time that each endpoint request has been fully received by the ASPSP and stopping when the last byte of the response message has been transmitted to the AISP. The following API endpoints should be included when calculating AISP response time, for each endpoint supported by the ASPSP:
Since different endpoints will have different payload sizes for request and response, and in order to facilitate a 'like for like' comparison with user/customer interfaces, the CBB recommends that ASPSPs also report on the average time per megabyte (MB). This can be calculated by dividing the total response time in milliseconds by the total payload response size in MB, across all API calls for all API endpoints for each day. | An Average TTLB of 750 milliseconds per response, or per page of results for up to 100 records for larger payloads. In practice, all but transactions and statements are likely to be small payloads without pagination |
Confirmation of Funds (CoF) response time (PISP) | For the purpose of calculating the performance indicators, the ASPSP should:
a) calculate the daily average time (in milliseconds) taken, per request, for the ASPSP to provide the PISP with a ‘yes/no’ confirmation
| The "time taken per request" should be calculated for each day using the mean value of Time to Last Byte (TTLB) measured in milliseconds, starting from the time that each endpoint request has been fully received by the ASPSP and stopping when the last byte of the response message (i.e. the 'yes/no' confirmation) has been transmitted to the PISP. The following API endpoints should be included when calculating CoF response times for PISP:
| An average TTLB of 300 and a max of 500 ms per response |
Daily error response rate | For the purpose of calculating the performance indicators, the ASPSP should:
a) calculate the daily error response rate – calculated as the number of error messages concerning errors attributable to the ASPSP sent by the ASPSP to the PISPs, or AISPs per day, divided by the number of requests received by the ASPSP from PISPs or AISPs in the same day
| It is not possible for ASPSPs to respond to AISPs/PISPs with an error message where no TLS (Transport layer security) session has been established. However, ASPSPs should still be able to respond, measure and report on errors relating to endpoint calls and all functional API calls. The error response rate should be calculated as the total number of all 5xx HTTP status codes from all API endpoints per day, divided by the total number of AISP/PISP API requests received across all of these endpoints in the same day, and expressed as a percentage. Errors based on 4xx HTTP status codes are largely attributable to AISP/PISP or user/customer actions or failures, and hence should not be included here. | An average of 0.5% across all endpoints |