Performance

Reference

Title

EBA requirement

OBIE calculation guidelines

OBIE recommended benchmark

EBA Guideline 2.3 (a)

PISP response time

…the ASPSP should define, at a minimum, the following KPIs for the performance of the dedicated interface:

a) the daily average time (in milliseconds) taken, per request, for the ASPSP to provide the payment initiation service provider (PISP) with all the information requested in accordance with Article 66(4)(b) of PSD2 and Article 36(1)(b) of the RTS;

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:

• POST /domestic-payments
• GET /domestic-payments/{DomesticPaymentId}
• GET /domestic-payments/{DomesticPaymentId}/payment-details
• POST /domestic-scheduled-payments
• GET /domestic-scheduled-payments/{DomesticScheduledPaymentId}
• GET /domestic-scheduled-payments/{DomesticScheduledPaymentId}/payment-details
• POST /domestic-standing-orders
• GET /domestic-standing-orders/{DomesticStandingOrderId
• GET /domestic-standing-orders/{DomesticStandingOrderId}/payment-details
• POST /international-payments
• GET /international-payments/{InternationalPaymentId}
• GET /international-payments/{InternationalPaymentId}/payment-details
• POST /international-scheduled-payments
• GET /international-scheduled-payments/{InternationalScheduledPaymentId}
• GET /international-scheduled-payments/{InternationalScheduledPaymentId}/payment-details
• POST /international-standing-orders
• GET /international-standing-orders/{InternationalStandingOrderPaymentId}
• GET /international-standing-orders/{InternationalStandingOrderPaymentId}/payment-details
• POST /file-payments
• GET /file-payments/{FilePaymentId}
• GET /file-payments/{FilePaymentId}/report-file
• GET /file-payments/{FilePaymentId}/payment-details

The ASPSP’s signed response to the POST will inherently act as proof of receipt of the payment order by the ASPSP, which will enable the TPP 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 requirements of PSD2 Article 66(4)(b), RTS Article 36(1)(b), i.e. for the ASPSP to make the information available to the PISP immediately after receipt of the payment order, and the FCA PSRs Approach Paragraph 17.29, i.e. 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 requirements of the PSRs Approach Paragraph 17.30, i.e. 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 PSU.

We note that because different endpoints will have different payload sizes for request and response (especially relevant for file payment endpoints involving large files), and in order to facilitate a ‘like for like’ comparison with PSU interfaces, OBIE 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 endpoint response for all but file payments.

EBA Guideline 2.3 (b)

AISP response time

b) the daily average time (in milliseconds) taken, per request, for the ASPSP to provide the account information service provider (AISP) with all the information requested in accordance with Article 36(1)(a) of the RTS;

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 times, for each endpoint supported by the ASPSP:

• GET /accounts
• GET /accounts/{AccountId}
• GET /accounts/{AccountId}/balances
• GET /balances
• GET /accounts/{AccountId}/transactions
• GET /transactions
• GET /accounts/{AccountId}/beneficiaries
• GET /beneficiaries
• GET /accounts/{AccountId}/direct-debits
• GET /direct-debits
• GET /accounts/{AccountId}/standing-orders
• GET /standing-orders
• GET /accounts/{AccountId}/product
• GET /products
• GET /accounts/{AccountId}/offers
• GET /offers
• GET /accounts/{AccountId}/party
• GET /party
• GET /accounts/{AccountId}/parties
• GET /accounts/{AccountId}/scheduled-payments
• GET /scheduled-payments
• GET /accounts/{AccountId}/statements
• GET /accounts/{AccountId}/statements/{StatementId}
• GET /accounts/{AccountId}/statements/{StatementId}/file
• GET/accounts/{AccountId}/statements/{StatementId}/transactions
• GET /statements

We note that because different endpoints will have different payload sizes for request and response, and in order to facilitate a ‘like for like’ comparison with PSU interfaces, OBIE 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.

EBA Guideline 2.3 (c)

Confirmation of Funds (CoF) response time (CBPII and PISP)

c) the daily average time (in milliseconds) taken, per request, for the ASPSP to provide the card-based payment instrument issuer (CBPII) or the PISP with a ‘yes/no’ confirmation in accordance with Article 65(3) of PSD2 and Article 36(1)(c) of the RTS;

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’ conformation) has been transmitted to the CBPII or PISP.

The following API endpoints should be included when calculating CoF response times for CBPII:

• POST /funds-confirmations

The following API endpoints should be included when calculating CoF response times for PISP: 

• GET /domestic-payment-consents/{ConsentId}/funds-confirmation
• GET /international-payment-consents/{ConsentId}/funds-confirmation
• GET /international-scheduled-payment-consents/{ConsentId}/funds-confirmation

An average TTLB of 300 and a max of 500 milliseconds per response.

This benchmark would not apply to complex corporate models, but rather simple account models only.

EBA Guideline 2.3 (d)

Daily error response rate

d) 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, AISPs and CBPIIs in accordance with Article 36(2) of the RTS per day, divided by the number of requests received by the ASPSP from AISPs, PISPs and CBPIIs in the same day.

It is not possible for ASPSPs to respond to TPPs with an error message where no TLS session has been established. However ASPSPs should still be able to respond, measure and report on errors relating to all OIDC endpoint calls and all functional API calls relating to the OBIE Standard.

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 TPP 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 TPP or PSU actions or failures, and hence should not be included here.

Cases where 2xx HTTP status codes are returned, but where the data in the response payload is not correct are covered in section Design and Testing.

An average of 0.5% across all endpoints