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:

• The total number of concurrent seconds per API call, per 24 hour period, starting and ending at midnight, that any element of the API is not available; divided by 86,400 (the number of seconds in 24 hours) and expressed as a percentage

• The clock for unavailability should start immediately after the first ‘failed’ request has been received within the 30 second timeframe

At a minimum, downtime should be measured if:

• Any ASPSP authorization and/or resource server is not fully accessible and accepting all valid AISP/PISP requests

• Any ASPSP downstream system required to support these API endpoints is also not responding in a way which effects the availability of the ASPSP authorization and/or resource servers

• Any of the ASPSP screens and/or functionality of the user/customer authentication flow is not available to enable users/customers to grant AISPs/PISPs access to their account(s)

• This should include all 5xx errors

• This should include both planned and unplanned downtime during each day

• Even if this only effects some AISPs/PISPs and/or users/customers, downtime should still be reported, i.e. partial downtime should still be measured as downtime

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 not directly attributable to 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).

#

Field Name

Description/ Definition

1

Performance and Availability

1.1

ReportDate

The reported date for each calendar day.

1.2

Entity Name

Reporting entity’s name.

1.3

Endpoint ID

Reported EndPoint ID as defined in the API Endpoint List of the Reporting Template. ASPSPs/ AISPs/ PISPs must only report endpoints that have gone live in their systems.

1.4

Uptime 

Uptime per each individual endpoint in hours and minutes. (Elapsed time)
For endpoints to be reported as available (uptime), they need to be fully operational in terms of fulfilling their functionality and being able to respond back to the requesting AISP/PISP. (i.e. no technical 5xx failures)

Calculated as 100% minus the total percentage downtime for each day.

1.5

Planned Downtime

Any planned duration that the API endpoints become unavailable. For the avoidance of doubt, this extends to include all systems that are required for the relevant endpoint to be fully functional.

1.6

Unplanned Downtime

Any unplanned duration that the API endpoints become unavailable due to technical faults or any other reasons. For the avoidance of doubt, this extends to include all systems that are required for the relevant endpoint to be fully functional.

1.7

Max Payment Initiations Per Second (PIPS)

This field is only applicable to Payment Initiation Service (PIS) endpoints. For Account Information Service (AIS) endpoints it should be populated with NULL. The maximum number of successful payment initiations per second (PIPS) for the payment order POST API calls. The PIPS must be reported as whole numbers. 

1.8

Average TTLB Response Time (Time to Last Byte)

The average (mean) value across all values of Time to Last Byte (TTLB) response time for each API endpoint. The response time clock should start at the point the endpoint call is fully received by the ASPSP and should stop at the point the last byte of the response message is transmitted to the AISP or PISP.
The response time must be reported in milliseconds.

1.9

Average TTFB Highest TTLB Response Time (Time to First Last Byte)

The average (mean) value across all values highest value of Time to First Last Byte (TTFBTTLB) response time for each API endpoint. The response time clock should start at the point the endpoint call is fully received by the ASPSP .

1.10

Total Number of API calls

This is the total number of API calls per day per endpointand should stop at the point the last byte of the response message is transmitted to the AISP or PISP. The response time must be reported in milliseconds.

1.1110

Total Lowest TTLB Response Time (Time to Last Byte)

This is the sum of The lowest value of Time to Last Byte (TTLB) response time for each API endpoint. The response time clock should start at the point the endpoint call is fully received by the ASPSP and should stop at the point the last byte of the response message is transmitted to the AISP or PISP. The response time must be reported in milliseconds.

1.11

Average TTFB Response Time (Time to First Byte)

The average (mean) value across all values of Time to First Byte (TTFB) response time for each API endpoint. The response time clock should start at the point the endpoint call is fully received by the ASPSP. The response time must be reported in milliseconds.

1.12

Highest TTFB Response Time (Time to First Byte)

The highest value of Time to First Byte (TTFB) response time for each API endpoint. The response time clock should start at the point the endpoint call is fully received by the ASPSP. The response time must be reported in milliseconds.

1.13

Lowest TTFB Response Time (Time to First Byte)

The lowest value of Time to First Byte (TTFB) response time for each API endpoint. The response time clock should start at the point the endpoint call is fully received by the ASPSP. The response time must be reported in milliseconds.

1.14

Total Number of API calls

This is the total number of API calls per day per endpoint.

1.15

Total TTLB Response Time (Time to Last Byte)

This is the sum of all the TTLB responses of all endpoint calls of each endpoint type. For the avoidance of doubt, this is the sum of all the TTLB response times generated by the total number of API calls for each endpoint.

1.1216

Total TTFB Response Time (Time to First Byte)

This is the sum of all the TTFB responses of all endpoint calls of each endpoint type. For the avoidance of doubt, this is the sum of all the TTFB response times generated by the total number of API calls for each endpoint.

1.1317

Total ResponsePayload Size

This is the sum of the payload of all the response messages for all endpoint calls of each endpoint type. For the avoidance of doubt, this is the sum of all the payloads of the response messages generated by the total number of API calls for each endpoint.

2

Authentication

2.1

ReportDate

The reported date for each calendar dayReportMonth

Reported calendar month and year (from 1st day of the month starting from 00:00:00 till last day of the month 23:59:59).

2.2

Entity Name

Reporting entity’s name.

2.3

Authentication Type

This is the type of authentication journeys provided by the ASPSP. It will include 'redirection' and where implemented 'decoupled' model.

2.4

API Type

This is the type of services that are being reported for the efficacy of the authentication journey. It includes Account Information Services (AIS) and Payment Initiation Services (PIS). 

2.5

API Request AISP/PISP Channel

This is the reported AISP/PISP channel for initiating the AIS or PIS consent. This may be provided by AISPsAISP/PISPs in the endpoint Request Header under the field 'x-customer-user-agent'. If the string cannot be mapped to a browser, then it will probably be a mobile app.

2.6

ASPSP Authentication Channel

This is the reported ASPSP Authentication channel. It can be web-based (Web) or using the mobile banking app (App).

2.7

Consents requiring Authentication

The total number of user/customer consents to require authentication at the ASPSP for the particular combination of authentication type, API type, AISP/PISP channel and ASPSP authentication channel.

2.8

Authentications Attempted by users/customers

The total number of authentications that have been attempted by the users/customers (not abandoned). This means that the Users/ Customers have tried to authenticate according to the authentication method required providing biometrics, username, passwords etc.

2.9

Authentications Abandoned by users/customers

The total number of user/customer consents to require authentication that has been abandoned by the users/customers.

2.10

Authentications Succeeded

The total number of consents requiring authentication that have completed authentications by users/customers and the authentications have succeeded.

2.11

Authentications Failed

The total number of consents requiring authentication that have completed authentications by users/customers and the authentications have failed.

2.12

Confirmations Required

The total number of consents requiring authorization, that after successful authentication, required a confirmation step.

2.13

Confirmations Accepted by user/customer

The total number of successful authentications that required a confirmation step and have been accepted by users/customers. This means that the users/customers proceeded with the access request or the payment order submission and did not cancel the process.

2.14

Confirmations Rejected by users/customers

The total number of successful authentications that required a confirmation step and have been rejected by users/customers. This means that the users/customers cancelled the process and did not proceed with the access request or the payment order submission.

3

User/ Customer Volumes

3.1

ReportMonth

Reported calendar month and year (from 1st day of the month starting from 00:00:00 till last day of the month 23:59:59).

3.2

Entity Name

Reporting entity’s name.

3.3

Retail/Business user/customer

This identifies Retail and Business users/customers for separate reporting.

3.4

User/Customer used AIS for the first time

The number of unique users/customers who have authorised access to their account(s) to one or more AISPs for account information services for the first time during the reporting period. For the avoidance of doubt, this refers to new consent/authorisations and not re-authorisationsauthorisations and not re-authorisations.

3.5

User/Customer re-authorised for using AIS

The total number of unique users/customers who have previously authorised access to their account(s) to one or more AISPs for account information services and had to re-authenticate to refresh the account access at least for one of the AISPs during the reporting period.

3.56

Total users/customers used AIS 

The total number of unique users/customers who:

a. have authorised access to their account(s) to one or more AISPs for account information services during the reporting period for the first time.

b. have previously authorised access to their account(s) to one or more AISPs for account information services and had their account accessed at least once by any of the AISPs during the reporting period.

c. have previously authorised access to their account(s) to one or more AISPs for account information services and had to re-authenticate to refresh the account access at least for one of the AISPs during the reporting period.

3.67

User/Customer used PIS for the first time

The number of unique user/customer who have authorised a payment initiation of any type from any of their account(s) via one or more PISPs for the first time during the reporting period. For the avoidance of doubt, a user/customer initiating a payment (e.g. single domestic) using a PISP A and then initiating another payment of different type (e.g. international) using a PISP B within the same ASPSP , should not be double-counted. For business customers, unique users/customers should refer to all employees of the business who have separate authentication credentials and can be identified separately. Multi-banked users/customers cannot be identified so they may be double-counted by different ASPSPs.

3.78

Total users/customers used PIS 

The total number of unique users/customers who:

a. have authorised a payment initiation of any type from any of their account(s) via one or more PISPs for the first time during the reporting period.

b. have authorised a payment initiation of any type from any of their account(s) via one or more PISPs during the reporting period and have initiated payments using PIS services before.

3.89

Unique users/customers used both AIS and PIS for the first time

Users/Customers accessing both AIS and PIS using the same authentication credentials.

3.910

Total unique users/customers used both AIS and PIS

Total users/customers accessing both AIS and PIS using the same authentication credentials. 

3.1011

Total new users/customers for Online Banking

The number of unique users/customers who have been granted access to Online Banking for the first time.

3.1112

Total new users/customers for Mobile Banking

The number of unique users/customers who have been granted access to Mobile Banking for the first time.

3.1213

Total number of users/customers used Online Banking

The total number of unique users/customers who have used the Online Banking service for either accessing account information or initiating a payment.

3.1314

Total number of users/customers used Mobile Banking

The total number of unique users/customers who have used the Mobile Banking service for either accessing account information or initiating a payment.

4

AISP/PISP Volumes

4.1

ReportMonth

Reported calendar month and year (from 1st day of the month starting from 00:00:00 till last day of the month 23:59:59).

4.2

Entity Name

Reporting entity’s name.

4.3

Total AISPs Registered (at 1st of the month) 

This is the cumulative total number of AISP’s, that have been already been on-boarded into the live environment (i.e. production environment) with the ASPSP as at the 1st of the reported month.

4.4

AISP Additions

This is the number of AISPs that have been on-boarded into the live environment (i.e. production environment) during the reported month.

4.5

AISP Deregistrations

This is the number of AISPs, that have been deregistered with the ASPSP during the reported month.

4.6

Cumulative Monthly number of AISPs 

This is the cumulative total number of AISP’s, that have been already been on-boarded into the live environment (i.e. production environment) with the ASPSP as at the end of the reported month.

4.7

Total PISPs Registered (at 1st of the month)

This is the cumulative total number of PISP’s, that have been already been on-boarded into the live environment (i.e. production environment) with the ASPSP as at the 1st of the reported month.

4.8

PISP Additions

This is the number of PISPs that have been on-boarded into the live environment (i.e. production environment) during the reported month.

4.9

PISP Deregistrations

This is the number of PISPs, that have been deregistered with the ASPSP during the reported month.

4.10

Cumulative Monthly number of PISPs 

This is the cumulative total number of PISP’s, that have been already been on-boarded into the live environment (i.e. production environment) with the ASPSP as at the end of the reported month.

5

Daily Volumes

5.1

ReportDate

The reported date for each calendar day.

5.2

Entity Name

Reporting entity’s name.

5.3

Endpoint ID

Reported EndPoint ID as defined in the API endpoint list of the Reporting Template. ASPSPs must only report endpoints that have gone live in their systems.

5.4

Successful API Calls (200, 201 or 204 codes)

This is the total number of successful endpoint calls for each endpoint that have been received successfully by the ASPSP and generated an AISP/PISP Status Code of 200, 201 or 204 depending on the HTTP method of the endpoints.

5.5

Failed API Calls Business Reasons (4xx Codes)

This is the total number of failed endpoint calls for each endpoint that have been received by the ASPSP and failed due to business rules reasons generating an HTTP Status Code of 4xx)generating an HTPP Status Code of 4xx). Kindly refer to the global standards of HTTPS Status Code Registry (https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml) for individual type of error codes/messages.

5.6

Failed API Technical Calls Reasons (5xx Codes)

This is the total number of failed endpoint calls for each endpoint that have been received by the ASPSP and failed due to technical reasons (generating an HTTP HTPP Status Code of 500 Internal Server Error)-599). Kindly refer to the global standards of HTTPS Status Code Registry (https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml) for individual type of error codes/messages.

5.7

API Calls Rejected Status

This is the total number of rejected endpoint calls that have been rejected for each defined endpoint which might be due payment/account consent being rejected due to authorisation failing or consent authorisation being rejected, payment initiation being rejected as part of proceeding checks such as technical validation and customer profile.