icon_search Search
Close X

HOW CAN WE HELP?

# MI Reporting Data API Specification

# 1. Reporting Template Key Usage Instructions

  • ASPSPs must submit MI Data to OBIE using this template and as defined in the Read-Write API Reporting and MI SLA document.
  • ASPSPs must populate the template using the API Endpoint IDs as defined in the section API Endpoint List.
  • ASPSPs must populate the template using the ASPSP Brand IDs as defined in the section ASPSP Brand List.
  • MI template for reporting required under OBIE is marked within brackets in the relevant tab names (1-9).
  • ASPSPs must not submit any empty entries. NULL should always be populated in cells which are not relevant to an ASPSP's implementation MI.
  • The Logical Data Dictionary for each field in the template file is defined below in section 3.
  • Reported MI data in all Template tabs must exclude ASPSP test application data generated during ASPSPs testing own implementations.
  • Note on reporting availability of endpoints: For endpoints to be reported as available, they need to be fully operational in terms of fulfilling their functionality and being able to respond back to the requesting TPP (i.e. no technical 5xx failures). However, this should exclude cases of network errors outside the ASPSP control or cases of TPPs becoming unavailable. For further details, please refer to section 1.1.
  • For the avoidance of doubt, in tab 3. Auth Efficacy (OBIE), fields M (Confirmation Required), N (Confirmation Accepted by PSUs) and O (Confirmation Rejected by PSUs) relate only to journeys, when during authentication at the ASPSP, the PSU needs to select their payment account and/ or the ASPSP needs to provide supplementary information to the PSU. In these instances, the PSU would need to click 'confirm to complete the authentication journey, as per the journeys defined in the OBIE Customer Experience Guidelines CEGs. Thus, single journeys such as Refreshing AISP access and Single Domestic Payments ā€“ a/c selection @ PISP are excluded together with any other case where other journeys defined in the CEGs may be presented without any additional confirmation step.
  • Version Reporting: Where ASPSPs support more than one major or minor API version in production, each version must be reported separately. For example, v3.0 and v3.1 must be reported separately. However patches, for example, v3.1.1, should be reported as aggregate together with the relevant major or minor release (i.e. together with v3.1). Note: Version reporting will not be mandatory for all the MI Reporting data. Please refer to each table in section 3 of the Data Dictionary for more details in terms of mandatory and optional version reporting.
  • The template reflects the requirements in the MI Requirement for ASPSPs proposition paper MI Requirements v3.1.7 for ASPSPs - FINAL.

# 1.1 Unavailability Definition (Downtime)

# 1.1.1 Dedicated Interface Downtime

In alignment to the EBA Guidelines 2.2.b: "count the interface as ā€˜downā€™ when five consecutive requests for access to information for the provision of payment initiation services, account information services or confirmation of the availability of funds are not replied to within a total timeframe of 30 seconds, irrespective of whether these requests originate from one or multiple PISPs, AISPs or CBPIIs. 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." In alignment to OBIE Operational Guidelines section 2.1.1: 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 authorisation and/or resource server is not fully accessible and accepting all valid TPP requests as defined by EBA Guidelines 2.4c.
  • Any ASPSP downstream system required to support these API endpoints is also not responding in a way which aaffectsthe availability of the ASPSP authorisation and/or resource servers.
  • Any of the ASPSP screens and/or functionality of the PSU authentication flow is not available to enable PSUs to grant TPPs access to their account(s).
  • This should include all 5xx errors.
  • This should include both planned and unplanned downtime each day.
  • Even if this only aaffectssome TPPs and/or PSUs, 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, e.g.
  • the ASPSP's own hosting provider,
  • any QTSP the ASPSP has selected for their own certificates,
  • a third party directory service (e.g. the OBIE Directory).

However, this should exclude errors resulting from issues outside of the ASPSP's direct control, such as any of the following:

  • Issues with TPP software, infrastructure or connectivity.
  • Lack of response/availability from an individual QTSP resulting in the inability of the ASPSP to check the validity of a TPP's eIDAS certificate, since it is the TPP who has selected the QTSP.

The above guidelines relate only to how ASPSPs should calculate downtime. ASPSPs must be mindful of their own regulatory obligations under the PSD2 regulatory framework and eIDAS Regulation.

# 1.1.2 PSU Interface Downtime

In alignment to OBIE Operational Guidelines section Reporting for PSU Interfaces: "The total time in seconds for each day when any element of the PSU interface is not accessible by the PSU in the process of accessing their PSD2 in-scope account, and in order to access PSD2 functionality"

# 2. Predefined Lists

# 2.1 API Endpoint List

EndpointID Resource Endpoint name Service Implementation Status Category Response Time Segment*
0 OIDC OIDC endpoints for token IDs OIDC Mandatory OIDC Ta & Te
1 account-access-consents POST /account-access-consents AISP Mandatory Account Information - Account access Consent Tb
2 account-access-consents GET /account-access-consents/{ConsentId} AISP Mandatory Account Information - Account access Consent N/A
3 account-access-consents DELETE /account-access-consents/{ConsentId} AISP Mandatory Account Information - Account access Consent N/A
4 accounts GET /accounts AISP Mandatory Account Information - Account Tf
5 accounts GET /accounts/{AccountId} AISP Mandatory Account Information -Accounts Tg
6 balances GET /accounts/{AccountId}/balances AISP Mandatory Account Information -Balances Tg
7 balances GET /balances AISP Optional Account Information -Balances Tg
8 transactions GET /accounts/{AccountId}/transactions AISP Mandatory Account Information -Transactions Tg
9 transactions GET /transactions AISP Optional Account Information -Transactions Tg
10 beneficiaries GET /accounts/{AccountId}/beneficiaries AISP Conditional Account Information -Beneficiaries Tg
11 beneficiaries GET /beneficiaries AISP Optional Account Information -Beneficiaries Tg
12 direct-debits GET /accounts/{AccountId}/direct-debits AISP Conditional Account Information -Direct Debits Tg
13 direct-debits GET /direct-debits AISP Optional Account Information -Direct Debits Tg
14 standing-orders GET /accounts/{AccountId}/standing-orders AISP Conditional Account Information -Standing Orders Tg
15 standing-orders GET /standing-orders AISP Optional Account Information -Standing Orders Tg
16 products GET /accounts/{AccountId}/product AISP Conditional Account Information - Product Tg
17 products GET /products AISP Optional Account Information -Products Tg
18 offers GET /accounts/{AccountId}/offers AISP Conditional Account Information - Offers Tg
19 offers GET /offers AISP Optional Account Information - Offers Tg
20 party GET /accounts/{AccountId}/party AISP Conditional Account Information - Party Tg
21 party GET /party AISP Conditional Account Information - Party Tg
22 scheduled-payments GET /accounts/{AccountId}/scheduled-payments AISP Conditional Account Information - Scheduled Payments Tg
23 scheduled-payments GET /scheduled-payments AISP Optional Account Information - Scheduled Payments Tg
24 statements GET /accounts/{AccountId}/statements AISP Conditional Account Information - Statements Tg
25 statements GET /accounts/{AccountId}/statements/{StatementId} AISP Conditional Account Information - Statements Tg
26 statements GET /accounts/{AccountId}/statements/{StatementId}/file AISP Optional Account Information - Statements Tg
27 statements GET /accounts/{AccountId}/statements/{StatementId}/transactions AISP Conditional Account Information - Statements Tg
28 statements GET /statements AISP Optional Account Information - Statements Tg
29 domestic-payment-consents POST /domestic-payment-consents PISP Mandatory Payments - Single Domestic Payment Tb
30 domestic-payment-consents GET /domestic-payment-consents/{ConsentId} PISP Mandatory Payments - Single Domestic Payment N/A
31 domestic-payments POST /domestic-payments PISP Mandatory Payments - Single Domestic Payment Tg
32 domestic-payments GET /domestic-payments/{DomesticPaymentId} PISP Mandatory Payments - Single Domestic Payment Th
33 domestic-scheduled-payment-consents POST /domestic-scheduled-payment-consents PISP Conditional Payments - Future Dated Domestic Payment Tb
34 domestic-scheduled-payment-consents GET /domestic-scheduled-payment-consents/{ConsentId} PISP Mandatory (if resource POST implemented) Payments - Future Dated Domestic Payment N/A
35 domestic-scheduled-payments POST /domestic-scheduled-payments PISP Conditional Payments - Future Dated Domestic Payment Tg
36 domestic-scheduled-payments GET /domestic-scheduled-payments/{DomesticScheduledPaymentId} PISP Mandatory (if resource POST implemented) Payments - Future Dated Domestic Payment Th
37 domestic-standing-order-consents POST /domestic-standing-order-consents PISP Conditional Payments - Domestic Standing Order Tb
38 domestic-standing-order-consents GET /domestic-standing-order-consents/{ConsentId} PISP Mandatory (if resource POST implemented) Payments - Domestic Standing Order N/A
39 domestic-standing-orders POST /domestic-standing-orders PISP Conditional Payments - Domestic Standing Order Tg
40 domestic-standing-orders GET /domestic-standing-orders/{DomesticStandingOrderId} PISP Mandatory (if resource POST implemented) Payments - Domestic Standing Order Th
41 international-payment-consents POST /international-payment-consents PISP Conditional Payments - International Payments Tb
42 international-payment-consents GET /international-payment-consents/{ConsentId} PISP Mandatory (if resource POST implemented) Payments - International Payments N/A
43 international-payments POST /international-payments PISP Conditional Payments - International Payments Tg
44 international-payments GET /international-payments/{InternationalPaymentId} PISP Mandatory (if resource POST implemented) Payments - International Payments Th
45 international-scheduled-payment-consents POST /international-scheduled-payment-consents PISP Conditional Payments - International Scheduled Payments Tb
46 international-scheduled-payment-consents GET /international-scheduled-payment-consents/{ConsentId} PISP Mandatory (if resource POST implemented) Payments - International Scheduled Payments N/A
47 international-scheduled-payments POST /international-scheduled-payments PISP Conditional Payments - International Scheduled Payments Tg
48 international-scheduled-payments GET /international-scheduled-payments/{InternationalScheduledPaymentId} PISP Mandatory (if resource POST implemented) Payments - International Scheduled Payments Th
49 international-standing-order-consents POST /international-standing-order-consents PISP Conditional Payments - International Standing Order Tb
50 international-standing-order-consents GET /international-standing-order-consents/{ConsentId} PISP Mandatory (if resource POST implemented) Payments - International Standing Order N/A
51 international-standing-orders POST /international-standing-orders PISP Conditional Payments - International Standing Order Tg
52 international-standing-orders GET /international-standing-orders/{InternationalStandingOrderPaymentId} PISP Mandatory (if resource POST implemented) Payments - International Standing Order Th
53 file-payment-consents POST /file-payment-consents PISP Conditional Payments - Bulk/Batch Payments Tb
54 file-payment-consents GET /file-payment-consents/{ConsentId} PISP Conditional Payments - Bulk/Batch Payments N/A
55 file-payment-consents POST /file-payment-consents/{ConsentId}/file PISP Mandatory (if resource POST implemented) Payments - Bulk/Batch Payments Tb
56 file-payment-consents GET /file-payment-consents/{ConsentId}/file PISP Conditional Payments - Bulk/Batch Payments N/A
57 file-payments POST /file-payments PISP Conditional Payments - Bulk/Batch Payments Tg
58 file-payments GET /file-payments/{FilePaymentId} PISP Mandatory (if resource POST implemented) Payments - Bulk/Batch Payments Th
59 file-payments GET /file-payments/{FilePaymentId}/report-file PISP Conditional Payments - Bulk/Batch Payments Th
60 funds-confirmation-consent POST /funds-confirmation-consents CoF Mandatory CBPII - Confirmation of Funds Tb
61 funds-confirmation-consent GET /funds-confirmation-consents/{ConsentId} CoF Mandatory CBPII - Confirmation of Funds N/A
62 funds-confirmation-consent DELETE /funds-confirmation-consents/{ConsentId} CoF Mandatory CBPII - Confirmation of Funds N/A
63 funds-confirmation POST /funds-confirmations CoF Mandatory CBPII - Confirmation of Funds Tf
64 payments POST /payments PIS Mandatory Payments - Single Domestic Payment Tb
65 payments GET /payments/{PaymentId} PIS Optional Payments - Single Domestic Payment N/A
66 payment-submissions POST /payment-submissions PIS Mandatory Payments - Single Domestic Payment Tg
67 payment-submissions GET /payment-submissions/{PaymentSubmissionId} PIS Optional Payments - Single Domestic Payment Th
68 account-requests POST /account-requests AIS Mandatory Account Information - Account access Consent Tb
69 account-requests GET /account-requests/{AccountRequestId} AIS Optional Account Information - Account access Consent N/A
70 account-requests DELETE /account-requests/{AccountRequestId} AIS Mandatory Account Information - Account access Consent N/A
71 Callback-url POST /callback-urls Notifications Optional Notifications - Call Back N/A
72 Callback-url GET /callback-urls Notifications Mandatory (if resource POST implemented) Notifications - Call Back N/A
73 Callback-url PUT /callback-urls/{CallbackUrlId} Notifications Mandatory (if resource POST implemented) Notifications - Call Back N/A
74 Callback-url DELETE /callback-urls/{CallbackUrlId} Notifications Mandatory (if resource POST implemented) Notifications - Call Back N/A
75 domestic-payment-consents GET /domestic-payment-consents/{ConsentId}/funds-confirmation CoF Mandatory Payments - Confirmation of Funds Tf
76 international-payment-consents GET /international-payment-consents/{ConsentId}/funds-confirmation CoF Mandatory (if resource POST implemented) Payments - Confirmation of Funds Tf
77 international-scheduled-payment-consents GET /international-scheduled-payment-consents/{ConsentId}/funds-confirmation CoF Mandatory (if immediate debit supported) Payments - Confirmation of Funds Tf
78 party GET /accounts/{AccountId}/parties AISP Conditional Account Information - Party Tg
79 domestic-payments GET /domestic-payments/{DomesticPaymentId}/payment-details PISP Optional Payments - Single Domestic Payment Th
80 domestic-scheduled-payments GET /domestic-scheduled-payments/{DomesticScheduledPaymentId}/payment-details PISP Optional Payments - Future Dated Domestic Payment Th
81 domestic-standing-orders GET /domestic-standing-orders/{DomesticStandingOrderId}/payment-details PISP Optional Payments - Domestic Standing Order Th
82 international-payments GET /international-payments/{InternationalPaymentId}/payment-details PISP Optional Payments - International Payments Th
83 international-scheduled-payments GET /international-scheduled-payments/{InternationalScheduledPaymentId}/payment-details PISP Optional Payments - International Scheduled Payments Th
84 international-standing-orders GET /international-standing-orders/{InternationalStandingOrderPaymentId}/payment-details PISP Optional Payments - International Standing Order Th
85 file-payments GET /file-payments/{FilePaymentId}/payment-details PISP Optional Payments - Bulk/Batch Payments Th
86 Event Notification Subscriptions POST /event-subscriptions Notifications Optional Notifications - Events N/A
87 Event Notification Subscriptions GET /event-subscriptions Notifications Mandatory (if resource POST implemented) Notifications - Events N/A
88 Event Notification Subscriptions PUT /event-subscriptions/{EventSubscriptionId} Notifications Mandatory (if resource POST implemented) Notifications - Events N/A
89 Event Notification Subscriptions DELETE /event-subscriptions/{EventSubscriptionId} Notifications Mandatory (if resource POST implemented) Notifications - Events N/A
90 Real-time Event Notifications POST /event-notifications Notifications Optional Notifications - Real-Time N/A
91 Aggregated Polling Notifications POST /events Notifications Optional Notifications - Aggregated Polling N/A
92 Authorization code** Generated OIDC Authorisation code (virtual endpoint) OIDC N/A OIDC Td
9999 Other Endpoint code Other Endpoint code General N/A N/A N/A

Endpoint ID 9999 allows stakeholders to publish any new endpoint which is not available in the above list. The Other Endpoint block will be used for this purpose.
Note: Using the Endpoint ID and the OBIE Standards version in the reporting tables, provides a unique identifier for each of the reported endpoints of the ASPSPs' implementation.
(*) For the definitions and more details on the time segments, please refer to section5.1 Measuring Performance for AISP, PISP and CBPII.
(**) This is not a real OIDC endpoint as such, but it is simply an entry (a virtual endpoint) to be used for measuring the time period (Td) of the authorisation code generation by ASPSPs. For more details, please refer to section 5.1 Measuring Performance for AISP, PISP and CBPII.

# 2.2. ASPSP Brand List

Note: The below list will be dynamic and will be amended as new ASPSPs and Brands are introduced. New entries will be added at the end of the list, so existing IDs are not expected to change.

ASPSP Brand ID ASPSP Brand Name
1 AIB First Trust Bank
2 AIB Group (UK) p.l.c.
3 Bank of Ireland UK
4 Bank of Scotland
5 Barclays
6 Danske Bank
7 First Direct
8 Halifax
9 HSBC
10 Lloyds
11 M&S Bank
12 Nationwide Building Society
13 Natwest
14 RBS
15 Santander UK plc
16 UBN
17 HSBC Business
18 MBNA
19 BĆ³
20 HSBC Kinetic
21 Cater Allen
9999 Other Brand code

ASPSP Brand ID 9999 allows stakeholders to publish any new Brand which is not available in the above list. The Other Brand block will be used for this purpose.

# 3. Logical Data Dictionary

The following tables are the Logical Data Dictionary explaining the fields in the MI Reporting Template.

# 3.1 Performance and Availability (P & A)

TAB: 1. P & A (OBIE)

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportDate The reported date for each calendar day ISODate Mandatory A particular point in the progression of time in a calendar year expressed in the YYYY-MM-DD format. This representation is defined in "XML Schema Part 2: Datatypes Second Edition - W3C Recommendation 28 October 2004" which is aligned with ISO 8601.
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Mandatory An integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 Endpoint ID Reported EndPoint ID as defined in section 2.1 API Endpoint List.
Note: ASPSPs must only report endpoints that have gone live in their systems.		 Number Mandatory An integer value in range 0-9999. Will be extended as new endpoints are being implemented by Open Banking future standards.
4 Core/Non-Core Hours (8.4/8.5) Used for reporting the availability and performance of each individual endpoint during core hours (06.00-0.00) and non-core hours (0.00-06.00) of each calendar day Max40Text Mandatory Allowed enumeration values: - Core Hours (06.00 - 00.00) - Non-Core Hours (00.00 - 06.00)
5 Uptime (8.4/8.5) Uptime per each individual endpoint in hours and minutes. (Elapsed time)
Note on reporting availability of endpoints: 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 TPP (i.e. no technical 5xx failures). However, this should exclude cases of network errors outside the ASPSP control or cases of TPPs becoming unavailable. For further details, please refer to section 1.1.1
Total uptime is calculated as:
1. Core Hours: Uptime = Total number of core hours (18:00) - Total Planned Downtime (hh:mm) - Total Unplanned Downtime (hh:mm)
2. Non-Core Hours: Uptime = Total number of non-core hours (6:00) - Total Planned Downtime (hh:mm) - Total Unplanned Downtime (hh:mm)		 Max5Text Mandatory ^[0-1][0-5]:[0-5][0-9]$ Hours and seconds text in the following format: "hh: mm" Max value: A) Core Hours: 18:00, B) Non Core Hours: 06:00 Min value: A) Core Hours: 00:00, B) Non-Core Hours: 00:00 Conditions 1. Core Hours: Uptime + Planned Downtime + Unplanned Downtime = 18 hours 2. Non-Core Hours: Uptime + Planned Downtime + Unplanned Downtime = 6 hours
6 Planned Downtime (8.4/8.5) 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 (Refer to A. Guidelines item 9). The clock for unavailability should start immediately and consolidated duration must be reported during core hours and non-core hours, as elapsed time. Due to per-minute granularity, rounding is expected to take place to the nearest whole minute (e.g. 1 min 15 sec should be reported as 1 min, 1 min 40 sec should be reported as 2 min).
For further details, please refer to section 1.1.1		 Max5Text Mandatory ^[0-1][0-5]:[0-5][0-9]$ Hours and seconds text in the following format: "hh: mm" Conditions 1. Core Hours: Uptime + Planned Downtime + Unplanned Downtime = 18 hours 2. Non-Core Hours: Uptime + Planned Downtime + Unplanned Downtime = 6 hours
7 Unplanned Downtime (8.4/8.5) 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 (For further details, please refer to section 1.1.1). The clock for unavailability should start as defined in section 1.1.1 and consolidated duration must be reported during core hours and non-core hours, as elapsed time. Due to per-minute granularity, rounding is expected to take place to the nearest whole minute (e.g. 1 min 15 sec should be reported as 1 min, 1 min 40 sec should be reported as 2 min). Max5Text Mandatory ^[0-1][0-5]:[0-5][0-9]$ Hours and seconds text in the following format: "hh:mm" Conditions 1. Core Hours: Uptime + Planned Downtime + Unplanned Downtime = 18 hours 2. Non-Core Hours: Uptime + Planned Downtime + Unplanned Downtime = 6 hours
8 Median TTLB Response Time (Time to Last Byte) (8.6/8.7/8.8) The median value across all values of Time to Last Byte (TTLB) response time for each API endpoint during the duration of core and non-core hours (e.g. a Get Account Transactions Request generates a Get Account Transactions Response message). Time to Last Byte (TTLB) is defined in the context of the OBIE reporting template as the total time taken for an API endpoint call to generate a response message and provide to AISPs, PISPs or CBPIIs all the information as required as defined in 36(1)(a), 36(1)(b), 36(1)(c) of the RTS and 66(4)(b), 65(3) of the PSD2. 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, PISP, or CBPII. For further clarifications on TTLB and TTFB, please refer to the Notes section at the end of the table.
The response time must be reported in milliseconds as follows:
1. Core Hours: Median (TTLB response time of each endpoint call of a specific type between 06.00 and 0.00 excluding the endpoint downtime)
2. Non Core Hours: Median (TTLB response time of each endpoint call of a specific type between 00.00 and 06.00 excluding the endpoint downtime).
If an endpoint is unavailable during the whole of the reported period, response time should be zero.		 Number Mandatory Integer number with value >=0 Values in milliseconds Conditions 1. TTLB >= TTFB
9 Median TTFB Response Time (Time to First Byte) (8.9) The median value across all values of Time to First Byte (TTFB) response time for each API endpoint during the duration of core and non-core hours (e.g. a Get Account Transactions Request generates a Get Account Transactions Response message). Time to First Byte (TTFB) is defined in the context of the OBIE reporting template as the total time taken for an API endpoint call to generate a response message and start providing to AISPs, PISPs or CBPIIs all the information as required as defined in 36(1)(a), 36(1)(b), 36(1)(c) of the RTS and 66(4)(b), 65(3) of the PSD2. 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 first byte of the response message is transmitted to the AISP, PISP, or CBPII. For further clarifications on TTLB and TTFB, please refer to the Notes section at the end of the table.
The response time must be reported in milliseconds as follows:
1. Core Hours: Median (TTFB response time of each endpoint call of a specific type between 06.00 and 0.00 excluding the endpoint downtime)
2. Non Core Hours: Median (TTFB response time of each endpoint call of a specific type between 00.00 and 06.00 excluding the endpoint downtime) If an endpoint is unavailable during the whole of the reported period, response time should be zero.		 Number Mandatory Integer number with value >=0 Values in milliseconds Conditions 1. TTLB >= TTFB
10 Median ResponsePayload Size (8.10) The median value across all values of Response Payload for each API endpoint during the duration of core and non-core hours (e.g. a Get Account Transactions Request generates a Get Account Transactions Response message). The response payload size of the response message to each supported Read/Write API endpoints must also include the size of the message headers. The Response Payload must be reported in bytes as follows:
1. Core Hours: Median (Response payload of each endpoint call of a specific type between 06.00 and 0.00 excluding the endpoint downtime)
2. Non Core Hours: Median (Response payload of each endpoint call of a specific type between 00.00 and 06.00 excluding the endpoint downtime) If an endpoint is unavailable during the whole of the reported period, the response payload should be zero.		 Number Mandatory Integer number with value >=0 Values in Bytes
11 Max Payment Initiations Per Second (PIPS) (8.12) This field is only applicable to PIS endpoints. For AIS and CBPII endpoints it should be populated with NULL. The maximum number of successful payment initiations per second (PIPS) for the payment order POST API calls during the duration of core and non-core hours.
The PIPS must be reported as whole numbers as follows:
1. Core Hours: Max (number of payment initiation POST endpoint calls during the period of 1 sec, for all 1 second periods between 06.00 and 0.00 excluding the endpoint downtime)
2.Non-Core Hours: Max (number of payment initiation POST endpoint calls during the period of 1 sec, for all 1 second periods between 00.00 and 06.00 excluding the endpoint downtime)		 Max4AlphaNumericText Mandatory Integer number Max value: 9999 Min value: 0 Not applicable: NULL
12 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 during the duration of core and non-core hours (e.g. a Get Account Transactions Request generates a Get Account Transactions Response message). Time to Last Byte (TTLB) is defined in the context of the OBIE reporting template as the total time taken for an API endpoint call to generate a response message and provide to AISPs, PISPs or CBPIIs all the information as required as defined in 36(1)(a), 36(1)(b), 36(1)(c) of the RTS and 66(4)(b), 65(3) of the PSD2. 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, PISP, or CBPII.
The response time must be reported in milliseconds as follows:
1. Core Hours: Mean (TTLB response time of each endpoint call of a specific type between 06.00 and 0.00 excluding the endpoint downtime)
2. Non-Core Hours: Mean (TTLB response time of each endpoint call of a specific type between 00.00 and 06.00 excluding the endpoint downtime) If an endpoint is unavailable during the whole of the reported period, response time should be zero.		 Number Mandatory Integer number with value >=0 Values in milliseconds Conditions 1. TTLB >= TTFB
13 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 during the duration of core and non-core hours (e.g. a Get Account Transactions Request generates a Get Account Transactions Response message). Time to First Byte (TTFB) is defined in the context of the OBIE reporting template as the total time taken for an API endpoint call to generate a response message and start providing to AISPs, PISPs or CBPIIs all the information as required as defined in 36(1)(a), 36(1)(b), 36(1)(c) of the RTS and 66(4)(b), 65(3) of the PSD2. 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 first byte of the response message is transmitted to the AISP, PISP, or CBPII.
The response time must be reported in milliseconds as follows:
1. Core Hours: Mean (TTFB response time of each endpoint call of a specific type between 06.00 and 0.00 excluding the endpoint downtime)
2. Non-Core Hours: Mean (TTFB response time of each endpoint call of a specific type between 00.00 and 06.00 excluding the endpoint downtime) If an endpoint is unavailable during the whole of the reported period, response time should be zero.		 Number Mandatory Integer number with value >=0 Values in milliseconds Conditions 1. TTLB >= TTFB
14 Total Number of API calls This is the total number of API calls per day per endpoint, per brand split by core/non-core. Number Mandatory Integer number with value >=0
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 during the period of core hours or non-core hours. 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. Number Mandatory Integer number with value >=0
16 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 during the period of core hours or non-core hours. 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. Number Mandatory Integer number with value >=0
17 Total ResponsePayload Size This is the sum of the payload of all the response messages for all endpoint calls of each endpoint type during the period of core hours or non-core hours. 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. Number Mandatory Integer number with value >=0
18 Version The OBIE Standards version of the endpoint implementation by the ASPSP, aggregated at the level of a major or minor release, as defined in item#10 of Section 1 key usage instructions. Max40Text Mandatory Allowed enumeration values: v1.0, v1.1, v2.0, v3.0, v3.1,...

Notes:
  1. Please refer to the diagram below for the difference between TTFB and TTLB.
    While TTLB measures the full time taken for a response from an endpoint call to be provided back to the TPP (which may be subject to external network delays or delays in the TTPs' systems in receiving the data), TTFB is looking to measure the internal latency within each ASPSP.
    Thus, TTFB provides the time taken for the ASPSP to fetch the required data from their internal downstream systems and make them available to be sent to the TPP via the ASPSP API gateway.
    Please also note that:
    - The TTFB timings may exclude the time taken by infrastructure, network devices and network infrastructure that is not part of the ASPSPā€™s infrastructure (e.g. DNS servers, ISP gateways etc.)
    - The TTFB timing must not exclude the time taken by infrastructure, network devices and network infrastructure that is part of the ASPSPā€™s infrastructure (this includes but is not limited to devices such as firewalls, WAFs, SSL termination devices, load balancers, API gateway etc.) Performance Availability
  2. For further clarifications, please refer to the following diagram (kindly provided by Barclays):
    TTFB Definitions
    t1: The timestamp recorded when the request is initially received by the Gateway.
    t2: The time when the request was initiated to the next available service.
    t3: The time when the request write was started.
    t4: The response time for each service.
    t5: This is the read time for response content.
    t6: The timestamp when the request write was initiated.
    t7: The overall time taken between receipt of the incoming request and streaming of the complete response to the client.

    Based on the above diagram and definitions:
    TTLB = time period (t7) - (t1)
    TTFB = time period (t6) - (t1)
    Also the following holds: TTLB = TTFB + (t7)

# 3.1-A PSU Authentication & Interaction (OPTIONAL)

The reporting of the fields in the table below is Optional for ASPSPs.

TAB: 1-A. PSU Authentication & Interaction

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportDate The reported date for each calendar day ISODate Optional A particular point in the progression of time in a calendar year expressed in the YYYY-MM-DD format. This representation is defined in "XML Schema Part 2: Datatypes Second Edition - W3C Recommendation 28 October 2004" which is aligned with ISO 8601.
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Optional An integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 API Type This is the type of OBIE services that are being reported for the PSU authentication and interaction timings. journey. It includes Account Information Services (AIS), Payment Initiation Services (PIS) and Card-Based Payment Instrument Issuers (CBPIIs). Max40Text Optional Allowed enumeration values: - AIS - PIS - CBPII
4 Time C PSU Authentication & Interaction (ms) (OPTIONAL) This is the total Tc total time taken for all the PSU consent journeys during the duration of a reporting day. Each Tc time period is the time taken for the PSU to complete the authentication process. For the avoidance of doubt, this is the time measured in seconds from the point in time the PSU, after being redirected to the authentication screen of the ASPSP Authorisation Server, submits the credentials for authentication, completes authentication and any other actions (such as selecting accounts or providing consent), until control is passed back to the ASPSP to start the process of generating the authorisation code. More details, please refer to section 5.1 Measuring Performance for AISP, PISP and CBPII. Number Optional A decimal number, with 2 decimal points granularity, with value >=0.00
5 PSU Authentications & Interactions Volumes (OPTIONAL) This is the Vc, which is the total volume of PSU authentications that generated the total response time Tc total It is the total number of PSU consent journeys that generated PSU authentication during the duration of a reporting day. More details, please refer to section 5.1 Measuring Performance for AISP, PISP and CBPII. Max20AlphaNumericTex Optional Integer number with value >=0
6 Version The OBIE Standards version of the implementation by the ASPSP, aggregated at the level of a major or minor release, as defined in item#10 of Section 1 key usage instructions. The reporting of this item is optional. Max40Text Optional Allowed enumeration values: v1.0, v1.1, v2.0, v3.0, v3.1,...

# 3.2 Response Outliers (OBIE)

Outlier response time in the context of the OBIE reporting template is defined as the API endpoint with TTLB response time of value that qualifies to be included in the set of Slowest 50 of all endpoints during both Core Hours (06.00-0.00) and non-Core Hours (0.00-06.00) of the service and when the API endpoints are available. The Slowest 50 data set is the top 50 endpoints with the highest percentage of their TTLB response being greater than the median TTLB value for this endpoint for the day (i.e top 50 endpoints with the highest value for the delay ratio TTLB / median (TTLBs for the endpoint during the day the endpoint call happened). For the avoidance of doubt, calculations are as follows: During Core Hours:

  • For each endpoint calculate delay ratio = TTLB/ (median TTLB of all endpoints calls for the endpoint type during core hours of the day the endpoint was called)

During non-Core Hours:

  • For each endpoint calculate delay ratio = TTLB/ (median TTLB of all endpoint calls for the endpoint type during non-core hours of the day the endpoint was called)

Slowest 50 across all endpoints of all types for all hours (core and non-core) during the reporting period (i.e. one month) is the set of the 50 endpoints with the highest delay ratio from all the calculated delay ratio values during the reporting period. Note: OBIE will be reviewing the fixed number (i.e. 50) of outliers submitted as part of the above definition and maybe be fine-tuning this figure in future iterations of the Data Dictionary.

TAB: 2. Response Outliers (OBIE)

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportDate Reported date (calendar day) for the outlier endpoint call ISODate Mandatory A particular point in the progression of time in a calendar year expressed in the YYYY-MM-DD format. This representation is defined in "XML Schema Part 2: Datatypes Second Edition - W3C Recommendation 28 October 2004" which is aligned with ISO 8601.
2 ReportTime Reported time for the outlier endpoint call ISOTime Mandatory A particular point in the progression of time in a calendar day expressed in either UTC time format (hh:mm:ss.sss), local time with UTC offset format (hh:mm:ss.sss+/-hh:mm), or local time format (hh:mm:ss.sss). These representations are defined in "XML Schema Part 2: Datatypes Second Edition - W3C Recommendation 28 October 2004" which is aligned with ISO 8601.
Note on the time format:
1) beginning/end of the calendar day 00:00:00 = the beginning of a calendar day 24:00:00 = the end of a calendar day
2) fractions of second in time format Decimal fractions of seconds may be included. In this case, the involved parties shall agree on the maximum number of digits that are allowed. UTC time format (hh:mm:ss)
3 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Mandatory An integer value in range 1-9999. Will be extended as new Brands join Open Banking
4 Endpoint ID Reported EndPoint ID as defined in section 2.1 API Endpoint List. Note: ASPSPs must only report endpoints that have gone live in their systems. Number Mandatory An integer value in range 0-9999. Will be extended as new endpoints are being implemented by Open Banking future standards.
5 TTLB Response Time (Time to Last Byte) (8.6/8.7/8.8) The Time to Last Byte (TTLB) response time for the API endpoint that generated an outlier from the overall data set of TTLB response times (e.g. a Get Account Transactions Request generates a Get Account Transactions Response message with response time being an outlier).
Please note that as per the current definitions, the metric to be used for identifying the outlier will be the value of the TTLB response. This is because the TTLB time includes the TTFB time as per the definitions used in the context of OBIE reporting and thus most probably would cover the cases where TTFB would also be an outlier.
Time to Last Byte (TTLB) is defined in the context of the OBIE reporting template as the total time taken for an API endpoint call to generate a response message and provide to AISPs, PISPs or CBPIIs all the information as required as defined in 36(1)(a), 36(1)(b), 36(1)(c) of the RTS and 66(4)(b), 65(3) of the PSD2. 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, PISP, or CBPII.
The response time must be reported in milliseconds.		 Number Mandatory Integer number with value >=0 Values in milliseconds
Conditions
1. TTLB >= TTFB
Cross-Table Condition with table Performance and Availability (P & A)
TTLB of outlier endpoint > median TTLB for this endpoint for the day (as reported in Table Performance and Availability (P & A)
6 TTFB Response Time (Time to First Byte) (8.9) The Time to First Byte (TTFB) response time for the API endpoint that generated an outlier from the overall data set of TTLB response times (e.g. a Get Account Transactions Request generates a Get Account Transactions Response message with response time being an outlier). Time to First Byte (TTFB) is defined in the context of the OBIE reporting template as the total time taken for an API endpoint call to generate a response message and start providing to AISPs, PISPs or CBPIIs all the information as required as defined in 36(1)(a), 36(1)(b), 36(1)(c) of the RTS and 66(4)(b), 65(3) of the PSD2. 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 first byte of the response message is transmitted to the AISP, PISP, or CBPII.
The response time must be reported in milliseconds.		 Number Mandatory Integer number with value >=0 Values in milliseconds Conditions 1. TTLB >= TTFB
7 TPP Application ID This is the unique ID assigned to a TPP during their registration with the OBIE Directory for a specific application. This is the field 'software_id; in the Software Statement Assertion (SSA). It is this TPP application that made the API endpoint call that generated the outlier. Max16Text Mandatory
8 ResponsePayload Size The value of the Response Payload for the API endpoint that generated the outlier (e.g. a Get Account Transactions Request generates a Get Account Transactions Response message with response time being an outlier) The response payload size of the response message to the supported Read/Write API endpoints must also include the size of the message headers. The Response Payload must be reported in bytes. Number Mandatory Integer number with value >=0 Values in Bytes
9 Version The OBIE Standards version of the endpoint implementation by the ASPSP, aggregated at the level of a major or minor release, as defined in item#10 of Section 1 key usage instructions. Max40Text Mandatory Allowed enumeration values: v1.0, v1.1, v2.0, v3.0, v3.1,...

# 3.3 Auth Efficacy (OBIE)

TAB: 3. Auth Efficacy (OBIE)

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportMonth Reported calendar month and year Max6Text Mandatory ^(Jan\|Feb\|Mar\|Apr\|May\|Jun\|Jul\|Aug\|Sep\|Oct\|Nov\|Dec)\-\d{2}$ (mmm-yy)
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Mandatory Integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 Authentication Type This is the type of authentication journeys provided by the ASPSP. It will include 'redirection' and where implemented 'decoupled' model. Max40Text Mandatory Allowed enumeration values: - Redirection - Decoupled As minimum Redirection data must be provided
4 API Type This is the type of OBIE services that are being reported for the efficacy of the authentication journey. It includes Account Information Services (AIS), Payment Initiation Services (PIS) and Card-Based Payment Instrument Issuers (CBPIIs) Max40Text Mandatory Allowed enumeration values: - AIS - PIS - CBPII
5 API Request TPP Channel (9.12/9.20/9.27/9.34) This is the reported TPP channel for initiating the AIs, PIS or CBPII consent. This may be provided by TPPs in the endpoint Request Header under the field 'x-customer-user-agent'. The reported value will be free format text however if populated by TPPs it will have well-known strings of characters for various popular browsers. If the string cannot be mapped to a browser, then it will probably be a mobile app. Future versions of CEG guidelines may recommend specific values to TPPs to provide in these fields some that better information is provided. Max40Text Mandatory Allowed enumeration values: - Browser - Non-Browser - Unknown
6 ASPSP Authentication Channel (9.13/9.21/9.28/9.35) This is the reported ASPSP Authentication channel. I can be web-based (Web) or using the mobile banking app (App) Max40Text Mandatory Allowed enumeration values: - Web - App - Unknown
7 Consents requiring Authentication (9.12/9.20/9.27/9.34) (9.13/9.21/9.28/9.35) The total number of PSU consents to require authentication at the ASPSP for the particular combination of authentication type, API type, TPP channel and ASPSP authentication channel. Number Mandatory Integer number with value >=0
8 Authentications Attempted by PSUs (9.14/9.36) The total number of authentications that have been attempted by the PSUs (not abandoned). This means that PSUs have tried to authenticate according to the authentication method required providing biometrics, username, passwords etc. Number Mandatory Integer number with value >=0 Conditions 1. Consents requiring Authentication >= Authentications Attempted by PSUs 2. Consents requiring Authentication = Authentications Attempted by PSUs + Authentications Abandoned by PSUs
9 Authentications Abandoned by PSUs (9.14/9.36) The total number of PSU consents to require authentication that has been abandoned by the PSUs. This means that PSUs do not undertake the authentication but instead have dropped the journey (they have left, closed the web page or app or allowed the authentication page to time out).
Note: Consents that have not been consumed by the TPP need to be included.		 Number Mandatory Integer number with value >=0 Conditions 1. Consents requiring Authentication >= Authentications Abandoned by PSUs 2. Consents requiring Authentication = Authentications Attempted by PSUs + Authentications Abandoned by PSUs
10 Authentications Succeeded (9.15/9.22/9.29/9.37) The total number of consents requiring authentication that have completed authentications by PSUs and the authentications have succeeded Number Mandatory Integer number with value >=0 Conditions 1. Authentications Attempted by PSUs >= Authentications Succeeded 2. Authentications Attempted by PSUs = Authentications Succeeded + Authentications Failed
11 Authentications Failed (9.16/9.23/9.30/9.37) The total number of consents requiring authentication that have completed authentications by PSUs and the authentications have failed Number Mandatory Integer number with value >=0 Conditions 1. Authentications Attempted by PSUs >= Authentications Failed 2. Authentications Attempted by PSUs = Authentications Succeeded + Authentications Failed
12 Confirmations Required (9.17/9.24/9.31/9.38) The total number of consents requiring authorisation, that after successful authentication, required a confirmation step. (Please refer to Section 1, item #9). Number Mandatory Integer number with value >=0 Conditions 1. Authentications Succeeded >= Confirmations Required
13 Confirmations Accepted by PSUs (9.18/9.25/9.32/9.39) The total number of successful authentications that required a confirmation step and have been accepted by PSUs. This means that the PSU proceeded with the access request or the payment order submission and did not cancel the process. (Please refer to Section 1, item #9). Number Mandatory Integer number with value >=0 Conditions 1. Confirmations Required >= Confirmations Accepted by PSUs 2. Confirmations Required = Confirmations Accepted by PSUs + Confirmations Rejected by PSUs
14 Confirmations Rejected by PSUs (9.19/9.26/9.33/9.39) The total number of successful authentications that required a confirmation step and have been rejected by PSUs. This means that the PSU cancelled the process and did not proceed with the access request or the payment order submission (Please refer to Section 1, item #9). Number Mandatory Integer number with value >=0 Conditions 1. Confirmations Required >= Confirmations Rejected by PSUs 2. Confirmations Required = Confirmations Accepted by PSUs + Confirmations Rejected by PSUs
15 Version The OBIE Standards version of the implementation by the ASPSP, aggregated at the level of a major or minor release, as defined in item#10 of Section 1 key usage instructions. Max40Text Mandatory Allowed enumeration values: v1.0, v1.1, v2.0, v3.0, v3.1,...

Cross-Table Condition(s) with Table Daily Volumes (OBIE)

A. SUM of 'Consents requiring Authentication' of All Combinations = SUM ('Successful API Calls' - 'API Calls Rejected Status' + 'API Calls Not Authorised by PSU') of API Calls with IDs #1 OR #68 for all days of the reporting period for the ASPSP Brand ID, (as reported in Table Daily Volumes (OBIE)
where All combinations = (Redirection, AIS, Browser, Web), (Redirection, AIS, Browser, App), (Redirection, AIS, Non-Browser, Web), (Redirection, AIS, Non-Browser, App), (Redirection, AIS, Non-Browser, App), (Decoupled, AIS, Browser, Web), (Decoupled, AIS, Browser, App), (Decoupled, AIS, Non-Browser, Web), (Decoupled, AIS, Non-Browser, App), (Decoupled, AIS, Non-Browser, App)

B. SUM of 'Consents requiring Authentication' of All Combinations = SUM ('Successful API Calls' - 'API Calls Rejected Status' + 'API Calls Not Authorised by PSU') of API Calls with IDs #29, #33, #37, #41, #45, #49, #53, OR #64 for all days of the reporting period for the ASPSP Brand ID, (as reported in Table Daily Volumes (OBIE) where All combinations = (Redirection, PIS, Browser, Web), (Redirection, PIS, Browser, App), (Redirection, PIS, Non-Browser, Web), (Redirection, PIS, Non-Browser, App), (Redirection, PIS, Non-Browser, App), (Decoupled, PIS, Browser, Web), (Decoupled, PIS, Browser, App), (Decoupled, PIS, Non-Browser, Web), (Decoupled, PIS, Non-Browser, App), (Decoupled, PIS, Non-Browser, App)

C. SUM of 'Consents requiring Authentication' of All Combinations = SUM ('Successful API Calls' - 'API Calls Rejected Status' + 'API Calls Not Authorised by PSU') of API Calls with IDs #60, for all days of the reporting period for the ASPSP Brand ID, (as reported in Table Daily Volumes (OBIE)
where All combinations = (Redirection, CBPII, Browser, Web), (Redirection, CBPII, Browser, App), (Redirection, CBPII, Non-Browser, Web), (Redirection, CBPII, Non-Browser, App), (Redirection, CBPII, Non-Browser, App), (Decoupled, CBPII, Browser, Web), (Decoupled, CBPII, Browser, App), (Decoupled, CBPII, Non-Browser, Web), (Decoupled, CBPII, Non-Browser, App), (Decoupled, CBPII, Non-Browser, App)

D. SUM of ('Authentications Succeeded' - 'Confirmations Required' + 'Confirmations Accepted by PSUs') of All Combinations = SUM ('Successful API Calls' - 'API Calls Rejected Status') of API Calls with IDs #1 OR #68, for all days of the reporting period for the ASPSP Brand ID, (as reported in Table Daily Volumes (OBIE)
where All combinations = (Redirection, AIS, Browser, Web), (Redirection, AIS, Browser, App), (Redirection, AIS, Non-Browser, Web), (Redirection, AIS, Non-Browser, App), (Redirection, AIS, Non-Browser, App), (Decoupled, AIS, Browser, Web), (Decoupled, AIS, Browser, App), (Decoupled, AIS, Non-Browser, Web), (Decoupled, AIS, Non-Browser, App), (Decoupled, AIS, Non-Browser, App)

E. SUM of ('Authentications Succeeded' - 'Confirmations Required' + 'Confirmations Accepted by PSUs') of All Combinations = SUM ('Successful API Calls' - 'API Calls Rejected Status') of API Calls with IDs #29, #33, #37, #41, #45, #49, #53, OR #64 for all days of the reporting period for the ASPSP Brand ID, (as reported in Table Daily Volumes (OBIE)
where All combinations = (Redirection, PIS, Browser, Web), (Redirection, PIS, Browser, App), (Redirection, PIS, Non-Browser, Web), (Redirection, PIS, Non-Browser, App), (Redirection, PIS, Non-Browser, App), (Decoupled, PIS, Browser, Web), (Decoupled, PIS, Browser, App), (Decoupled, PIS, Non-Browser, Web), (Decoupled, PIS, Non-Browser, App), (Decoupled, PIS, Non-Browser, App)

F. SUM of ('Authentications Succeeded' - 'Confirmations Required' + 'Confirmations Accepted by PSUs') of All Combinations = SUM ('Successful API Calls' - 'API Calls Rejected Status') of API Calls with IDs #60, for all days of the reporting period for the ASPSP Brand ID, (as reported in Table Daily Volumes (OBIE)
where All combinations = (Redirection, CBPII, Browser, Web), (Redirection, CBPII, Browser, App), (Redirection, CBPII, Non-Browser, Web), (Redirection, CBPII, Non-Browser, App), (Redirection, CBPII, Non-Browser, App), (Decoupled, CBPII, Browser, Web), (Decoupled, CBPII, Browser, App), (Decoupled, CBPII, Non-Browser, Web), (Decoupled, CBPII, Non-Browser, App), (Decoupled, CBPII, Non-Browser, App)

G. SUM of ('Authentications Abandoned by PSUs' + 'Authentications Failed' + 'Confirmations Rejected by PSUs') of All Combinations = SUM ('API Calls Not Authorised by PSU') of API Calls with IDs #1 OR #68, for all days of the reporting period for the ASPSP Brand ID, (as reported in Table Daily Volumes (OBIE)
where All combinations = (Redirection, AIS, Browser, Web), (Redirection, AIS, Browser, App), (Redirection, AIS, Non-Browser, Web), (Redirection, AIS, Non-Browser, App), (Redirection, AIS, Non-Browser, App), (Decoupled, AIS, Browser, Web), (Decoupled, AIS, Browser, App), (Decoupled, AIS, Non-Browser, Web), (Decoupled, AIS, Non-Browser, App), (Decoupled, AIS, Non-Browser, App)

H. SUM of ('Authentications Abandoned by PSUs' + 'Authentications Failed' + 'Confirmations Rejected by PSUs') of All Combinations = SUM ('API Calls Not Authorised by PSU') of API Calls with IDs #29, #33, #37, #41, #45, #49, #53, OR #64 for all days of the reporting period for the ASPSP Brand ID, (as reported in Table Daily Volumes (OBIE)
where All combinations = (Redirection, PIS, Browser, Web), (Redirection, PIS, Browser, App), (Redirection, PIS, Non-Browser, Web), (Redirection, PIS, Non-Browser, App), (Redirection, PIS, Non-Browser, App), (Decoupled, PIS, Browser, Web), (Decoupled, PIS, Browser, App), (Decoupled, PIS, Non-Browser, Web), (Decoupled, PIS, Non-Browser, App), (Decoupled, PIS, Non-Browser, App)

I. SUM of ('Authentications Abandoned by PSUs' + 'Authentications Failed' + 'Confirmations Rejected by PSUs') of All Combinations = SUM ('API Calls Not Authorised by PSU') of API Calls with IDs #60, for all days of the reporting period for the ASPSP Brand ID, (as reported in Table Daily Volumes (OBIE)
where All combinations = (Redirection, CBPII, Browser, Web), (Redirection, CBPII, Browser, App), (Redirection, CBPII, Non-Browser, Web), (Redirection, CBPII, Non-Browser, App), (Redirection, CBPII, Non-Browser, App), (Decoupled, CBPII, Browser, Web), (Decoupled, CBPII, Browser, App), (Decoupled, CBPII, Non-Browser, Web), (Decoupled, CBPII, Non-Browser, App), (Decoupled, CBPII, Non-Browser, App) Cross-Table Condition(s) with Table PSU Consent Adoption (OBIE)

J. SUM of ('Authentications Succeeded' - 'Confirmations Required' + 'Confirmations Accepted by PSUs') of All Combinations = 'One-off Consents' + 'Long-lived consents - Outstanding consents EoP' of API Service AIS for both Retail and Business PSUs during the reporting period for the ASPSP Brand ID, (as reported in Table PSU Consent Adoption (OBIE)
where All combinations = (Redirection, AIS, Browser, Web), (Redirection, AIS, Browser, App), (Redirection, AIS, Non-Browser, Web), (Redirection, AIS, Non-Browser, App), (Redirection, AIS, Non-Browser, App), (Decoupled, AIS, Browser, Web), (Decoupled, AIS, Browser, App), (Decoupled, AIS, Non-Browser, Web), (Decoupled, AIS, Non-Browser, App), (Decoupled, AIS, Non-Browser, App)

K. SUM of ('Authentications Succeeded' - 'Confirmations Required' + 'Confirmations Accepted by PSUs') of All Combinations = 'One-off Consents' of API Service PIS for both Retail and Business PSUs during the reporting period for the ASPSP Brand ID, (as reported in Table PSU Consent Adoption (OBIE)
where All combinations = (Redirection, PIS, Browser, Web), (Redirection, PIS, Browser, App), (Redirection, PIS, Non-Browser, Web), (Redirection, PIS, Non-Browser, App), (Redirection, PIS, Non-Browser, App), (Decoupled, PIS, Browser, Web), (Decoupled, PIS, Browser, App), (Decoupled, PIS, Non-Browser, Web), (Decoupled, PIS, Non-Browser, App), (Decoupled, PIS, Non-Browser, App)

L. SUM of ('Authentications Succeeded' - 'Confirmations Required' + 'Confirmations Accepted by PSUs') of All Combinations = 'Long-lived consents - Outstanding consents EoP' of API Service CBPII for both Retail and Business PSUs during the reporting period for the ASPSP Brand ID, (as reported in Table PSU Consent Adoption (OBIE)
where All combinations = (Redirection, CBPII, Browser, Web), (Redirection, CBPII, Browser, App), (Redirection, CBPII, Non-Browser, Web), (Redirection, CBPII, Non-Browser, App), (Redirection, CBPII, Non-Browser, App), (Decoupled, CBPII, Browser, Web), (Decoupled, CBPII, Browser, App), (Decoupled, CBPII, Non-Browser, Web), (Decoupled, CBPII, Non-Browser, App), (Decoupled, CBPII, Non-Browser, App)

# 3.4 PSU Adoption (OBIE)

TAB: 4. PSU Adoption (OBIE)

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportMonth Reported calendar month and year Max6Text Mandatory ^(Jan\|Feb\|Mar\|Apr\|May\|Jun\|Jul\|Aug\|Sep\|Oct\|Nov\|Dec)\-\d{2}$ (mmm-yy)
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Mandatory An integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 Retail/Business PSUs This identifies Retail and Business PSUs for separate reporting. Max40Text Mandatory Allowed enumeration values: - Retail - Business
4 PSUs used AIS Services for the first time (9.9) The number of unique PSUs (customers with one or more accounts with the ASPSP brand) 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-authorisations. A PSU providing account access to more than 1 AISP should not be double-counted. For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately. Multi-banked PSUs cannot be identified so they may be double-counted by different ASPSPs.
Note: The ā€˜historical durationā€™ that an ASPSP is required to check if a PSU had used these service before, must meet the following criteria:
1. The data range must be aligned to an ASPSPs corporate records and retention policy.
2. If the corporate records and retention policies do not cater for open banking services, the start date of the ā€˜historical durationā€™ period should commence from January 2018.
3. If there are consents which have a start date that go beyond the records retention policy criteria and are live consents, these consents must be available within the data.		 Number Mandatory Integer number with value >=0
5 PSUs used PIS Services for the first time (9.10) The number of unique PSUs (customers with one or more accounts with the ASPSP brand) 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 PSU initiating a payment (e.g. single domestic) using a PISP A from a PCA A and then initiating another payment of different type (e.g. international) using a PISP B from a PCA B within the same ASPSP brand, should not be double-counted. For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately. Multi-banked PSUs cannot be identified so they may be double-counted by different ASPSPs.
Note: The ā€˜historical durationā€™ that an ASPSP is required to check if a PSU had used these service before, must meet the following criteria:
1. The data range must be aligned to an ASPSPs corporate records and retention policy
2. If the corporate records and retention policies do not cater for open banking services, the start date of the ā€˜historical durationā€™ period should commence from January 2018.
3. The ā€˜historical durationā€™ must be a minimum of three years
4. The first payment in any given ā€˜historicalā€™ duration must be considered as the first time a PSU is PIS services.		 Number Mandatory Integer number with value >=0
6 Total PSUs used AIS Services (9.9) The total number of unique PSUs (customers with one or more accounts with the ASPSP brand) 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 (see PSUs used AIS Services 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.
For the avoidance of doubt, a PSU in case (c) re-authenticating their account access should not be double-counted if an AISP accesses their account after re-authentication. For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately.		 Number Mandatory Integer number with value >=0 If Retail/Business PSUs is 'Retail': NULL For Business PSUs, if Active PSUs >0 then Active SME Businesses >=0 For Business PSUs, if Active SME Businesses >0, then Active PSUs >0
7 Total PSUs used PIS Services (9.10) The total number of unique PSUs (customers with one or more accounts with the ASPSP brand) 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 (see PSUs used PIS Services for the first time)
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.
For the avoidance of doubt, a PSU initiating a payment (e.g. single domestic) using a PISP A from a PCA A and then initiating another payment of different type (e.g. international) using a PISP B from a PCA B within the same ASPSP brand, should not be double-counted. For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately.		 Number Mandatory Integer number with value >=0 Conditions 1. Total PSUs used PIS Services >= PSUs used PIS Services for the first time
8 Unique PSUs used both AIS and PIS Services for the first time PSUs accessing both AIS and PIS services using the same authentication credentials.
The number of unique PSUs (customers with one or more accounts with the ASPSP brand) who have:
a. authorised access to their account(s) to one or more AISPs for account information services for the first time during the reporting period.
AND
b. 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:
i. for AIS, this refers to new consent/authorisations and not re-authorisations. A PSU providing account access to more than 1 AISPs should not be double-counted. For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately.
ii. for PIS, a PSU initiating a payment (e.g. single domestic) using a PISP A from a PCA A and then initiating another payment of different type (e.g. international) using a PISP B from a PCA B within the same ASPSP brand, should not be double-counted. For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately.
Note: The ā€˜historical durationā€™ that an ASPSP is required to check if a PSU had used these services before, must meet the criteria stated in items #4 and #5 above (PSUs used AIS Services for the first time(9.9) and PSUs used PIS Services for the first time (9.10) respectively)		 Number Mandatory Integer number with value >=0
Conditions
1. Unique PSUs used both AIS and PIS Services for the first time <= PSUs used AIS Services for the first time
2. Unique PSUs used both AIS and PIS Services for the first time <= PSUs used PIS Services for the first time
3. Unique PSUs used both AIS and PIS Services for the first time <= PSUs used AIS Services for the first time + PSUs used PIS Services for the first time
9 Total unique PSUs used both AIS and PIS Services PSUs accessing both AIS and PIS services using the same authentication credentials.
The total number of unique PSUs (customers with one or more accounts with the ASPSP brand) 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 (see PSUs used AIS Services 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.
AND
d. 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 (see PSUs used PIS Services for the first time)
e. 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.
For the avoidance of doubt:
i. For AIS, a PSU in case (c) re-authenticating their account access should not be double-counted if an AISP accesses their account after re-authentication. For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately.
ii. For PIS, a PSU initiating a payment (e.g. single domestic) using a PISP A from a PCA A and then initiating another payment of different type (e.g. international) using a PISP B from a PCA B within the same ASPSP brand, should not be double-counted. For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately.		 Number Mandatory Integer number with value >=0
Conditions
1. Total unique PSUs used both AIS and PIS Services >= Unique PSUs used both AIS and PIS Services for the first time
2. Total unique PSUs used both AIS and PIS Services <= Total PSUs used AIS Services
3. Total unique PSUs used both AIS and PIS Services <= Total PSUs used PIS Services
4. Total unique PSUs used PIS Services <= Total PSUs used AIS Services + Total PSUs used PIS Services
11 Total new PSUs for Online Banking The number of unique PSUs (customers with one or more accounts with the ASPSP brand) who have been granted access to the Online Banking for the first time. Number Mandatory Integer number with value >=0
12 Total new PSUs for Mobile Banking The number of unique PSUs (customers with one or more accounts with the ASPSP brand) who have been granted access to the Mobile Banking for the first time. Number Mandatory Integer number with value >=0
13 Total number of PSUs used Online Banking The total number of unique PSUs (customers with one or more accounts with the ASPSP brand) who have used the Online Banking service for either accessing account information or initiating a payment.
Note: For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately.		 Number Mandatory Integer number with value >=0
Conditions
1. Total number of PSUs used Online Banking >= Total new PSUs for Online Banking
14 Total number of PSUs used Mobile Banking The total number of unique PSUs (customers with one or more accounts with the ASPSP brand) who have used the Mobile Banking service for either accessing account information or initiating a payment.
Note: For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately.		 Number Mandatory Integer number with value >=0
Conditions
1. Total number of PSUs used Mobile Banking >= Total new PSUs for Mobile Banking
15 Version The OBIE Standards version of the implementation by the ASPSP, aggregated at the level of a major or minor release, as defined in item#10 of Section 1 key usage instructions.
The reporting of this item is optional.		 Max40Text Optional Allowed enumeration values: v1.0, v1.1, v2.0, v3.0, v3.1,...

NOTE

Multi-Authorisation Journeys


In multi-authorisation journeys, after the first authoriser (i.e. the PSU providing consent and making the submission), subsequent authorisers (confirmatory PSUs in a multi-authorisation chain) do not need to be users of the PISP and hence they must not be counted as separate PSUs.

# 3.4-A Enhanced PSU Adoption (OBIE)

TAB: 4-A. Enhanced PSU Adoption (OBIE)

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportMonth Reported calendar month and year Max6Text Mandatory ^(Jan\|Feb\|Mar\|Apr\|May\|Jun\|Jul\|Aug\|Sep\|Oct\|Nov\|Dec)\-\d{2}$ (mmm-yy)
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Mandatory Integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 Retail/Business PSUs This identifies Retail and Business PSUs for separate reporting. Max40Text Mandatory Allowed enumeration values:
- Retail
- Business
4 API Service This identifies the API service the PSU is using, including Account Information (AIS), Payment Initiation (PIS) and Card-Based Payment Instrument Issuers (CBPII). Each service must be reported separately and also all the possible combinations of services a PSU maybe using offered by the ASPSP. The PSUs reported for each type of API service combination are distinct users in order to avoid double counting. Max40Text Mandatory Allowed enumeration values:
AIS_only
PIS_only
CBPII_only
AIS_&_PIS
AIS_&_CBPII
PIS_&_CBPII
AIS_&_PIS_&_CBPII
5 Active PSUs This is the total number of bank-level PSUs (i.e. the number of customers that give access to accounts for each of the API service combinations).
For the avoidance of doubt, this includes all customers (consumers and account holders of SME businesses) who;
For AIS_only API service:
1. Have an active long-lived AIS consent at the end of the reporting period OR
2. Have provided a one-off AIS consent during the current reporting period OR
3. Have both an active AIS consent at the end of the reporting period AND have provided a one-off AIS consent during the current reporting period (These must be counted as one PSU).
For PIS_only API s service:
4. Have provided a one-off PIS consent during the current reporting period (payment initiation instruction).
**For CBPII_only service: **
5. Have an active CBPII/CoF consent at the end of the reporting period.
For AIS_&_PIS service:
6. Have performed a combination of rules 1. to 3. AND rule 4. (These must be counted as one PSU)
For AIS_&_CBPII service:
7. Have performed a combination of rules 1. to 3. AND rule 5. (These must be counted as one PSU)
For PIS_&_CBPII service:
8. Have performed a combination of rule 4. AND 5. (These must be counted as one PSU)
For AIS_PIS_&_CBPII service:
9. Have performed a combination of rules 1. to 3. AND rule 4. AND rule 5.(These must be counted as one PSU)		 Number Mandatory Integer number with value >=0
AIS_only Active PSUs + PIS_only Active PSUs + CBPII_only Active PSUs + AIS_&_PIS Active PSUs + AIS_&_CBPII Active PSUs + PIS_&_CBPII Active PSUs + AIS_&_PIS_&_CBPII Active PSUs = Total Active PSUs within ASPSP (unique)
6 Active SME Businesses This is the total number of bank-level SME Business PSUs (i.e. the number of SME business customers that consented to give access to their accounts for each of the API service combinations).
For the avoidance of doubt, this is referring to the number of SME businesses which have consented and not the number of users of these businesses that have account access credentials to the businesses' accounts and have consented.
ASPSP should use their own definition of SME business (e.g. level of turnover).		 Max20AlphaNumericTex Mandatory Integer number with value >=0
If Retail/Business PSUs is 'Retail': NULL
For Business PSUs, if Active PSUs >0 then Active SME Businesses >0
For Business PSUs, if Active SME Businesses >0, then Active PSUs >=0
7 Version The OBIE Standards version of the implementation by the ASPSP, aggregated at the level of a major or minor release, as defined in item#10 of Section 1 key usage instructions.
The reporting of this item is optional.		 Max40Text Optional Allowed enumeration values:
v1.0, v1.1, v2.0, v3.0, v3.1,...

Notes:
Duplication challenges in counting bank-level PSUs.
In order to ease the computational burden on ASPSPs, it is proposed that they do not undertake de-duplication effort across brands and product types such as PCA, BCA and Credit cards (if the credit card associated consents cannot be easily filtered out). Please refer to the following rules:
Duplication of PSUs Rules:

  1. More than one brand: If an individual customer has accounts and provided access authorisation to more than one ASPSP brand of the same ASPSP Group, then the ASPSP Group is allowed to count the individual customer as multiple bank-level PSUs. This means that ASPSPs Groups do not need to de-duplicate across ASPSP brands, providing ease of computation.
  2. More than one product (e.g. PCA and BCA and credit card): if an individual customer has more than one account product and provided access authorisation for each of them to the ASPSP, then the ASPSP is allowed to count the individual customer as multiple bank-level PSUs. This means that ASPSPs do not need to de-duplicate across products, providing ease of computation.
  3. Joint Account: All members of a joint account who have consented are allowed to be counted as multiple bank-level PSUs.

However,

  • If a PSU has provided consent to multiple TPPs for the same account type (e.g. current account) in an ASPSP, then the ASPSP must count the PSU as one PSU.
  • If a PSU has provided consent to any combination of the API services of AIS, PIS or CBPII for the same account type (e.g. current account) in an ASPSP, then the ASPSP must count the PSU as one PSU.

Multi-Authorisation Journeys

In multi-authorisation journeys, after the first authoriser (i.e. the PSU providing consent and making the submission), subsequent authorisers (confirmatory PSUs in a multi-authorisation chain) do not need to be users of the PISP and hence they must not be counted as separate PSUs.

# 3.4-B PSU Consent Adoption (OBIE)

TAB: 4-B. PSU Consent Adoption (OBIE)

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportMonth Reported calendar month and year Max6Text Mandatory ^(Jan\|Feb\|Mar\|Apr\|May\|Jun\|Jul\|Aug\|Sep\|Oct\|Nov\|Dec)\-\d{2}$ (mmm-yy)
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Mandatory Integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 Retail/Business PSUs This identifies Retail and Business PSUs for separate reporting. Max40Text Mandatory Allowed enumeration values: - Retail - Business
4 API Service This identifies the API service the PSU consent to, including Account Information (AIS), Payment Initiation (PIS) or Card-Based Payment Instrument Issuers (CBPII). Consents for each service must be reported separately. The Consents reported for each type of API service are distinct (i.e. unique) consents. Max40Text Mandatory Allowed enumeration values: AIS PIS CBPII
5 One-off Consents This is the total unique One-off consents for AIS or PIS API services for each Consumer or Business PSU type of each ASPSP Brand.
For the avoidance of doubt this refers to:
- all payment consent resource types (including domestic-payment-consents, domestic-scheduled-payment-consents,domestic-standing-order-consents, international-payment-consents, international-scheduled-payment-consents, international-standing-order-consents and file-payment-consents) and
- account-access-consent resources with an expiry date of less or equal to 15 days duration from the day they have been authorised		 Number Mandatory Integer number with value >=0
6 Long-lived consents - Outstanding consents BoP This is the total number of unique Long-lived consents which are Outstanding at the beginning of the reporting period (BoP).
For the avoidance of doubt, outstanding consents refers to
- all consents which are active at the beginning of the reporting period.
- account-access-consent resources in ā€˜Authorisedā€™ state with an expiry date, if specified, of more than 15 days duration from the day they have been authorised, or no expiry date defined
Number Mandatory Integer number with value >=0
7 Long-lived consents - Revoked consents This is the total number of unique Long-lived consents which have been revoked by PSUs during the reporting period.
For the avoidance of doubt this refers to account-access-consent resources:
- with an expiry date, if specified, of more than 15 days duration from the day they have been authorised, or no expiry date defined
- that have been set to ā€˜revokedā€™ state during the reporting period
Number Mandatory Integer number with value >=0
8 Long-lived consents - Expired consents This is the total number of unique Long-lived consents which have expired during the reporting period. Note: This will exclude CBPII/CoF consents as these consents do not expire and need to be revoked.
For the avoidance of doubt this refers to account-access-consent resources:
- with an expiry date of more than 15 days duration from the day they have been authorised
- that the expiration Date Time has elapsed sometime during the reporting period and all access permissions previously consented have now been stopped.
Number Mandatory Integer number with value >=0
9 Long-lived consents - Consents Requiring Reauthentication This is the total number of unique Long-lived consents which required 90 days PSU re-authentication, as per the RTS requirements.
For the avoidance of doubt this refers to account-access-consent resources:- with an expiry date, if specified, of more than 15 days duration from the day they have been authorised, or no expiry date defined
- that have resource status of ā€˜Authorisedā€™
- that the expiry date, if specified, has not elapsed
- the PSU has not re-authenticated the account-access consent for 90 days.
 Number Mandatory Integer number with value >=0
10 Long-lived consents - Refreshed consents This is the total number of unique Long-lived consents which required PSU re-authentication due to the 90 days RTS requirement and have been refreshed (i.e. reauthenticated) by PSUs during the reporting period.
For the avoidance of doubt this refers to account-access-consent resources:
- with an expiry date, if specified, of more than 15 days duration from the day they have been authorised, or no expiry date defined
- that have resource status of ā€˜Authorisedā€™
- that the expiry date, if specified, has not elapsed
- that required PSU re-authentication due to the 90 days RTS requirement (as defined in item #9, Long-lived consents - Consents Requiring Reauthentication)
- the PSU has re-authenticated the account-access consent during the reporting period
Note: If the PSU re-authenticates the account-access consent, before the 90 days period, (i.e. the consent is not counted in item #9, Long-lived consents - Consents Requiring Reauthentication), then the PSU re-authentication should not be counted in this metric as well.
 Number Mandatory Integer number with value >=0
11 Long-lived consents - New consents This is the total number of unique new Long-lived consents which have been consented to by PSUs during the reporting period.
For the avoidance of doubt, new consents refer to account-access-consent resources:
- with an expiry date, if specified, of more than 15 days duration from the day they have been authorised,, or no expiry date defined
- that have resource status of ā€˜Authorisedā€™		 Number Mandatory Integer number with value >=0
12 Long-lived consents - Outstanding consents EoP This is the total number of unique Long-lived consents which are Outstanding at the end of the reporting period (EoP).
For the avoidance of doubt, outstanding consents refer to:
- all consents which are active at the end of the reporting period
- account-access-consent resources in ā€˜Authorisedā€™ state with an expiry date, if specified, of more than 15 days duration from the day they have been authorised, or no expiry date defined		 Number Mandatory Integer number with value >=0 Outstanding consents EoP = Outstanding consents BoP - Revoked consents - Expired consents + Renewed consents + New consents
13 Long-lived consents - Total Refreshed consents This is the total number of unique Long-lived consents which have been refreshed (i.e. reauthenticated) by PSUs during the reporting period.
For the avoidance of doubt this refers to account-access-consent resources:
- with an expiry date, if specified, of more than 15 days duration from the day they have been authorised, or no expiry date defined
- that have resource status of ā€˜Authorisedā€™
- that the expiry date, if specified, has not elapsed
- the PSU has re-authenticated the account-access consent during the reporting period, irrespective of whether they required PSU re-authentication due to the 90 days RTS requirement or not.		 Number Mandatory Integer number with value >=0
14 Version The OBIE Standards version of the implementation by the ASPSP, aggregated at the level of a major or minor release, as defined in item#10 of Section 1 key usage instructions.
The reporting of this item is optional.		 Max40Text Optional Allowed enumeration values:
v1.0, v1.1, v2.0, v3.0, v3.1,...

Notes:
In order to differentiate between one-off and long-lived consents, it is proposed that ASPSPs assume one-offs are any consents with an expiry of less or equal to 15 days.
The term ā€˜consentā€™ is used from a PSU perspective. From ASPSPā€™s perspective, it is the access given by the PSU to the TPP. Hence reporting should still be the access data statistics for the ASPSP.

A. Flow only data requirements:

One-off consents for AIS and payment instructions (PIS) should be tracked using a flow only model. AIS and PIS flows will be captured separately. The total number of consents passing through the flow only buckets will be summed for each reporting period.

B. Stock and Flow only data requirements:

It is proposed that long-lived consents follow a stock and flow model. This approach is used to identify active/long-lived consents at a specific point in time (i.e. end of the reporting period). These consents will be measured based on the rules below which follows a stock and flow model.

  • Outstanding consents beginning of the period (BoP)
  • Fewer consents revoked.
  • Fewer consents expired.
  • Fewer consents blocked requiring Re-Authentication
  • Plus consents Refreshed.
  • Plus new consents.
  • Outstanding consents at end of reporting period (EoP)

# 3.5 Payments Adoption (OBIE)

TAB: 5. Payments Adoption (OBIE)

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportMonth Reported calendar month and year Max6Text Mandatory ^(Jan\|Feb\|Mar\|Apr\|May\|Jun\|Jul\|Aug\|Sep\|Oct\|Nov\|Dec)\-\d{2}$ (mmm-yy)
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Mandatory Integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 Payment Type The payment types that a number of adoption metrics need to be reported.
Note:
The payment type now also includes Faster Payments and therefore Future Dated Payments and Standing Orders should also be included in the reported payments as they are processed by Faster Payments.
For the avoidance of doubt, the following endpoints would be in the reporting scope of this table:
- Faster Payments (endpoints #31, #35, #39 and #66)
- Bacs (endpoints #31, #35 and #66)
- CHAPS (endpoints #31, #35 and #66)
- Bulk (endpoints #57) International (endpoints #43, #47 and #51)		 Max40Text Mandatory Allowed enumeration values:
- Bacs
- CHAPS
- Bulk
- International
- Faster Payments
4 PSU Authorisations for single Domestic Payments (9.40/9.41) For single domestic payments, this is the total number of payment orders authorised by PSUs per the available payment type.
Note: For this item, OBIE is looking to receive the number of payment order consent calls (POST /domestic-payment-consents endpoint calls) which resulted in domestic-payment consent resources with state Authorised.		 Max20AlphaNumericText Mandatory Integer number with value >=0
If payment type is Bulk: NULL
If payment type is International: NULL
Cross-Table Condition(s) with Table Daily Volumes (OBIE) 'PSU Authorisations for single Domestic Payments' = SUM ('SuccessfulAPI Calls' - 'API Calls Rejected Status') of API Calls with IDs #29, #33, #37 and #64, for all days of the reporting period for the ASPSP Brand ID, (as reported in Table Daily Volumes (OBIE)
5 Successful single Domestic Payments (9.42/9.43) For single domestic payments, this is the total number of successful single domestic payment orders that have been accepted for execution per the available payment type.
Note: OBIE is focusing on the initiation of the payments and less the actual core banking transactions outcome. Thus for this item, OBIE is looking to receive the number of payment order calls (POST /domestic-payments endpoint calls) which resulted in domestic-payment resources with state AcceptedSettlementInProgress or AcceptedSettlementCompleted. This means that as a minimum, all preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution. This also assumes that that the payment order consent was also successful and has been authorised and consumed.		 Max20AlphaNumericText Mandatory Integer number with value >=0
If the payment type is Bulk: NULL
If the payment type is International: NULL
Conditions 1. Successful single Domestic Payments <= PSU Authorisations for single Domestic Payments Cross-Table Condition(s) with Table Daily Volumes (OBIE) 'Successful single Domestic Payments' = SUM ('SuccessfulAPI Calls' - 'API Calls Rejected Status') of API Calls with IDs as per the Payment Type field which resulted in domestic-payment resources with state AcceptedSettlementInProgress or AcceptedSettlementCompleted, for all days of the reporting period for the ASPSP Brand ID, (as reported in Table Daily Volumes (OBIE)
6 Single Domestic Payments failed for Business Reasons (4xx codes) (9.44/9.45) For single domestic payments, this is the total number of failed single domestic payment initiation endpoint calls that have failed due to business rules reasons (generating an HTPP Status Code of 4xx) per the available payment type. Max20AlphaNumericText Mandatory Integer number with value >=0
If the payment type is Bulk: NULL
If the payment type is International: NULL
Cross-Table Condition(s) with Table Daily Volumes (OBIE) 'Single Domestic Payments failed for Business Reasons (4xx codes)'** = SUM ('Failed API Calls Business Reasons (4xx codes)') **of API Calls with IDs as per the Payment Type field for all days of the reporting period for the ASPSP Brand ID, (as reported in Table Daily Volumes (OBIE)
7 Single Domestic Payments failed for Technical Reasons (500 codes) (9.44/9.45) For single domestic payments, this is the total number of failed single domestic payment initiation endpoint calls that have failed due to technical reasons (generating an HTPP Status Code of 500 Internal Server Error) per the available payment type. Max20AlphaNumericText Mandatory Integer number with value >=0
If the payment type is Bulk: NULL
If the payment type is International: NULL
Cross-Table Condition(s) with Table Daily Volumes (OBIE) 'Single Domestic Payments failed for Technical Reasons (500 codes)' = SUM ('Failed API Calls Technical Reasons (5xx codes)') of API Calls with IDs as per the Payment Type field for all days of the reporting period for the ASPSP Brand ID, (as reported in Table Daily Volumes (OBIE)
8 Single Domestic Payments Rejected (9.44/9.45) For single domestic payments, this is the total number of rejected single domestic payment initiation endpoint calls that have been rejected per the available payment type.
Note: OBIE is looking to receive the rejected payment initiation endpoint calls at every part of the payment initiation journey, including both the post of the domestic payment consent and post of the domestic payment order. The item refers to the number of these calls which resulted in domestic-payment resources in the rejected state due to payment initiation being rejected as part of preceding checks such as technical validation and customer profile.		 Max20AlphaNumericText Mandatory Integer number with value >=0
If the payment type is Bulk: NULL
If the payment type is International: NULL
Conditions
1. Single Domestic Payments Rejected <= PSU Authorisations for single Domestic Payments
2. (Single Domestic Payments Rejected + Successful single Domestic Payments) <= PSU Authorisations for single Domestic Payments Cross-Table Condition(s) with Table Daily Volumes (OBIE) 'Single Domestic Payments Rejected' = SUM ('API Calls Rejected Status') of API Calls with IDs as per the Payment Type field for all days of the reporting period for the ASPSP Brand ID, (as reported in Table Daily Volumes (OBIE)
9 Total payments included in Bulk/Batch files (9.46) This is the total number of payments (individual payment instructions) included in bulk/batch files sent to the ASPSP brand for payment initiation via PISPs. The number of transactions may be included in the field NumberOfTransactions of the POST /file-payment-consents endpoint call but this field is not mandatory to be populated by PISPs. The total number of transactions may also be included within the file submitted by the PISP and can be extracted from there. Please note that this number refers to the number of transactions included within the file and does not need to exclude any invalid transactions identified during validation. Max20AlphaNumericText Mandatory Integer number with value >=0
If the payment type is Bacs: NULL
If the payment type is CHAPS: NULL
If the payment type is International: NULL
If the payment type is FPS: NULL
10 Successful International payments involving currency conversion (9.47) This is the number of successful international payments initiated via PISPs that involved currency conversion. This is to be expressed as a percentage of the total successful international payments initiated via PISPs. For the avoidance of doubt, successful international payments refer to the number of international payment order calls (POST /international-payments endpoint calls) which resulted in international-payment resources with state AcceptedSettlementInProgress or AcceptedSettlementCompleted. This means that as a minimum, all preceding checks such as technical validation and customer profile were successful and therefore the international payment initiation has been accepted for execution. This also assumes that that the international payment order consent was also successful and has been authorised and consumed. In the context of the reporting template, currency conversion means that required currency for the international payment (e.g. USD) is different from the currency of the initiating (debit) account (e.g. GBP) and thus the ASPSP will perform currency conversion during the processing and execution of the payment. Max20AlphaNumericText Mandatory Percentage number with no decimal points with a value between 0% and 100%
If the payment type is Bacs: NULL
If the payment type is CHAPS: NULL
If the payment type is Bulk: NULL
If the payment type is FPS: NULL
11 Version The OBIE Standards version of the implementation by the ASPSP, aggregated at the level of a major or minor release, as defined in item#10 of Section 1 key usage instructions. Max40Text Mandatory Allowed enumeration values:
v1.0, v1.1, v2.0, v3.0, v3.1,...

# 3.6 TPP Volumes (OBIE)

TAB: 6. TPP Volumes (OBIE)

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportMonth Reported calendar month and year Max6Text Mandatory ^(Jan\|Feb\|Mar\|Apr\|May\|Jun\|Jul\|Aug\|Sep\|Oct\|Nov\|Dec)\-\d{2}$ (mmm-yy)
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Mandatory Integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 Total AISPs Registered (at 1st of the month) (9.1) 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. For the avoidance of doubt, OBIE is looking to receive the number of discrete AISPs (grouped by TPP ID i.e. OrgName) and not the number of discrete SSAs (i.e. SoftwareId) onboarded with the ASPSP. Number Mandatory Integer number with value >=0
Conditions
1.Total AISPs Registered (at 1st of month) = Cumulative Monthly number of AISPs (as reported on previous reported month)
4 AISP Additions (9.2) This is the number of AISPs that have been on-boarded into the live environment (i.e. production environment) during the reported month
For the avoidance of doubt, OBIE is looking to receive the number of discrete AISPs (grouped by TPP ID i.e. OrgName) and not the number of discrete SSAs (i.e. SoftwareId) onboarded with the ASPSP. However, if a TPP is registering as both an AISP and a PISP, it should be counted separately in each of the AISP and PISP entries.		 Number Mandatory Integer number with value >=0
5 AISP Deregistrations (9.3) This is the number of AISPs, that have been deregistered with the ASPSP during the reported month.
For the avoidance of doubt, OBIE is looking to receive the number of discrete AISPs (grouped by TPP ID i.e. OrgName) and not the number of discrete SSAs (i.e. SoftwareId) onboarded with the ASPSP.		 Number Mandatory Integer number with value >=0
Conditions
1.AISP Deregistrations <= Total AISPs Registered (at 1st of month)
6 Cumulative Monthly number of AISPs (9.4) 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.
For the avoidance of doubt, OBIE is looking to receive the number of discrete AISPs (grouped by TPP ID i.e. OrgName) and not the number of discrete SSAs (i.e. SoftwareId) onboarded with the ASPSP.		 Number Mandatory Integer number with value >=0
Conditions
1.Cumulative Monthly number of AISPs >= Total AISPs Registered (at 1st of month)
2. Cumulative Monthly number of AISPs = Total AISPs Registered (at 1st of month) + AISP Additions + AISP Deregistrations
7 Total PISPs Registered (at 1st of the month) (9.5) 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.
For the avoidance of doubt, OBIE is looking to receive the number of discrete PISPs (grouped by TPP ID i.e. OrgName) and not the number of discrete SSAs (i.e. SoftwareId) onboarded with the ASPSP. However, if a TPP is registering as both an AISP and a PISP, it should be counted separately in each of the AISP and PISP entries.		 Number Mandatory Integer number with value >=0 Conditions
1.Total PISPs Registered (at 1st of month) = Cumulative Monthly number of PISPs (as reported on previous reported month)
8 PISP Additions (9.6) This is the number of PISPs that have been on-boarded into the live environment (i.e. production environment) during the reported month
For the avoidance of doubt, OBIE is looking to receive the number of discrete PISPs (grouped by TPP ID i.e. OrgName) and not the number of discrete SSAs (i.e. SoftwareId) onboarded with the ASPSP. However, if a TPP is registering as both an AISP and a PISP, it should be counted separately in each of the AISP and PISP entries		 Number Mandatory Integer number with value >=0
9 PISP Deregistrations (9.7) This is the number of PISPs, that have been deregistered with the ASPSP during the reported month.
For the avoidance of doubt, OBIE is looking to receive the number of discrete PISPs (grouped by TPP ID i.e. OrgName) and not the number of discrete SSAs (i.e. SoftwareId) onboarded with the ASPSP.		 Number Mandatory Integer number with value >=0
Conditions
1.PISP Deregistrations <= Total PISPs Registered (at 1st of month)
10 Cumulative Monthly number of PISPs (9.8) 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.
For the avoidance of doubt OBIE is looking to receive the number of discrete PISPs (grouped by TPP ID i.e. OrgName) and not the number of discrete SSAs (i.e. SoftwareId) onboarded with the ASPSP.		 Number Mandatory Integer number with value >=0
Conditions
1. Cumulative Monthly number of PISPs >= Total PISPs Registered (at 1st of the month)
2. Cumulative Monthly number of PISPs = Total PISPs Registered (at 1st of month) + PISP Additions + PISP Deregistrations
11 Total CBPIIs Registered (at 1st of the month) This is the cumulative total number of CBPIIs, 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.
For the avoidance of doubt, OBIE is looking to receive the number of discrete CBPIIs (grouped by TPP ID i.e. OrgName) and not the number of discrete SSAs (i.e. SoftwareId) onboarded with the ASPSP. However, if a TPP is registering as a CBPII, AISP and/or a PISP, it should be counted separately in each of the CBPII, AISP and PISP entries.		 Number Optional Integer number with value >=0
Conditions
1.Total CBPIIs Registered (at 1st of the month) = Cumulative Monthly number of CBPIIs (as reported on previous reported month)
12 CBPII Additions This is the number of CBPIIs that have been onboarded into the live environment (i.e. production environment) during the reported month
For the avoidance of doubt OBIE is looking to receive the number of discrete CBPIIs (grouped by TPP ID i.e. OrgName) and not the number of discrete SSAs (i.e. SoftwareId) onboarded with the ASPSP. However, if a TPP is registering as a CBPII, AISP and/or a PISP, it should be counted separately in each of the CBPII, AISP and PISP entries.		 Number Optional Integer number with value >=0
13 CBPII Deregistrations This is the number of CBPIIs, that have been deregistered with the ASPSP during the reported month.
For the avoidance of doubt, OBIE is looking to receive the number of discrete CBPIIs (grouped by TPP ID i.e. OrgName) and not the number of discrete SSAs (i.e. SoftwareId) onboarded with the ASPSP.		 Number Optional Integer number with value >=0
Conditions
1.CBPII Deregistrations <= Total CBPIIs Registered (at 1st of the month)
14 Cumulative Monthly number of CBPIIs This is the cumulative total number of CBPIIs, 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.
For the avoidance of doubt OBIE is looking to receive the number of discrete CBPIIs (grouped by TPP ID i.e. OrgName) and not the number of discrete SSAs (i.e. SoftwareId) onboarded with the ASPSP.		 Number Optional Integer number with value >=0
Conditions
1. Cumulative Monthly number of CBPIIs >= Total CBPIIs Registered (at 1st of the month) 2. Cumulative Monthly number of CBPIIs= Total CBPIIs Registered (at 1st of the month) + CBPII Additions + CBPII Deregistrations
15 Version The OBIE Standards version of the implementation by the ASPSP, aggregated at the level of a major or minor release, as defined in item#10 of Section 1 key usage instructions.
The reporting of this item is optional.		 Max40Text Optional Allowed enumeration values:
v1.0, v1.1, v2.0, v3.0, v3.1,...

# 3.7 Daily Volumes (OBIE)

TAB: 7. Daily Volumes (OBIE)

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportDate Reported date for each calendar day ISODate Mandatory A particular point in the progression of time in a calendar year expressed in the YYYY-MM-DD format. This representation is defined in "XML Schema Part 2: Datatypes Second Edition - W3C Recommendation 28 October 2004" which is aligned with ISO 8601.
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Mandatory An integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 Endpoint ID Reported EndPoint ID as defined in section 2.1 API Endpoint List. Note: ASPSPs must only report endpoints that have gone live in their systems. Number Mandatory An integer value in range 0-9999. Will be extended as new endpoints are being implemented by Open Banking future standards.
4 PCA API Calls (9.11) This is the number of API endpoint calls for each API endpoint that has been send to the ASPSP Brand for AIS account access, PIS payment initiations or CoF access from PCA accounts. The reporting of this item is optional. Max20AlphaNumericText Optional Integer number with value >=0 If PCA accounts reporting not provided, then the value should be NULL
Conditions
1. Total number of API calls for each endpoint >= PCA API Calls
5 BCA API Calls (9.11) This is the number of API endpoint calls for each API endpoint that has been send to the ASPSP Brand for AIS account access, PIS payment initiations or CoF access from BCA accounts. Note: ASPSPs that do not support BCA accounts will be reporting in column E PCA only. However, they are also required to fill in the BCA F column with NULL. The reporting of this item is optional. Max20AlphaNumericText Optional Integer number with value >=0
If BCA accounts reporting not provided, then the value should be NULL
If BCA accounts not supported, then the value should be NULL
Conditions
1.Total number of API calls for each endpoint >= BCA API Calls 2. Total number of API calls for each endpoint >= PCA API Calls + BCA API Calls
6 Successful API Calls (200, 201 or 204 codes) (10.1/10.2/10.3/10.4) This is the total number of successful endpoint calls for each endpoint that have been received successfully by the ASPSP brand and generated a HTPP Status Code of 200, 201 or 204 depending on the HTTP method of the endpoints. Number Mandatory Integer number with value >=0
7 Failed API Calls Business Reasons (4xx codes) (10.5) This is the total number of failed endpoint calls for each endpoint that have been received by the ASPSP brand and failed due to business rules reasons generating an HTPP Status Code of 4xx). Number Mandatory Integer number with value >=0
8 Failed API Calls Technical Reasons (5xx codes) (10.6) This is the total number of failed endpoint calls for each endpoint that have been received by the ASPSP brand and failed due to technical reasons (generating an HTPP Status Code of 500 Internal Server Error).
Note: ASPSPs should exclude the impact of 5xx calls where a TPP continues to call their services during a period of Planned Outage.
For the avoidance of doubt, this means that these endpoint calls will not be reported.		 Number Mandatory Integer number with value >=0
Conditions
1. Total number of API calls for each endpoint = Successful API Calls + Failed API Calls Business Reasons (4xx codes) + Failed API Calls Technical Reasons (5xx codes)
2. Total number of API calls for each endpoint >= Successful API Calls 3. Total number of API calls for each endpoint >= Failed API Calls Business Reasons (4xx codes)
4. Total number of API calls for each endpoint >= Failed API Calls Technical Reasons (5xx codes)
9 API Calls Rejected Status (10.7/10.8) This is the total number of rejected endpoint calls that have been rejected for each endpoint.
Note: The item refers to the number of endpoint calls which resulted in:
a. payments consent resources in the rejected state due to authorisation failing or consent authorisation being rejected
b. payment resources in the rejected state due to payment initiation being rejected as part of proceeding checks such as technical validation and customer profile c. account access consent resources in the rejected state due to authorisation failing or consent authorisation being rejected d. funds-confirmation-consent resources in the rejected state due to authorisation failing or consent authorisation not agreed.		 Number Mandatory Integer number with value >=0
Conditions
1. Total number of API calls for each endpoint >= API Calls Rejected Status
2. Successful API Calls >= API Calls Rejected Status
10 TPPs Calling APIs (10.9) This is the number of individual TPPs calling each API end-point. For the avoidance of doubt OBIE is looking to receive the number of discrete TPPs (grouped by TPP ID) and not the number of discrete SSAs onboarded with the ASPSP making the endpoint calls. Number Mandatory Integer number with value >=0
11 API Calls Not Authorised by PSU (10.10) This is the total number of successful endpoint calls that have been presented to the PSU for authorisation and the PSU have not authorised.
Note: The item refers to the number of endpoint calls which resulted in:
a. payments consent resources in AwaitingAuthorisation state that have moved to Rejected state due to PSU not authorising the consent.
b. account access consent resources in AwaitingAuthorisation state that have moved to Rejected state due to due to PSU not authorising the consent. c. funds-confirmation-consent resources in AwaitingAuthorisation state that have moved to Rejected state due to due to PSU not authorising the consent. The NULL value must be reported for any other endpoint.		 Max20AlphaNumericText Mandatory Integer number with value >=0
If the HTTP method of the endpoint is not POST, then the value should be NULL
Conditions
1.Total number of API calls for each endpoint >= API Calls Not Authorised by PSU
2.Successful API Calls >= API Calls Not Authorised by PSU
3. API Calls Rejected Status >= API Calls Not Authorised by PSU 4. API Calls Rejected due to validation = API Calls Rejected Status - API Calls Not Authorised by PSU
5. API Calls Requiring PSU Authorisation = Successful API Calls - API Calls Rejected due to validation
6. API Calls Authorised by PSUs = API Calls Requiring PSU Authorisation - API Calls Not Authorised by PSU
12 API Calls Authorised but Not Consumed (10.11) This is the total number of successful endpoint calls that have been authorised by PSUs but the payment order has not been submitted by the PISPs.
Note: The item refers to the number of endpoint calls which resulted in:
a. payments consent resources in Authorised state that have not moved to Consumed state due to PISP not making a call to the payment order endpoint call.
NULL value must be reported for any other endpoint.		 Max20AlphaNumericText Mandatory Integer number with value >=0
If the endpoint is not a payment consent POST, then the value should be NULL.
Conditions
1. API Calls Authorised but Not Consumed <= API Calls Authorised by PSUs
13 Multi Auth API Calls Successful (10.12) This is the number of PIS endpoint calls that required multiple authorisations and have been fully authorised successfully. This only applies to payment initiation. In the context of this template reporting, for multi-auth payments, a successful payment initiation occurs once a complete payment order has been submitted to the ASPSP (i.e. once all PSU authorisers have authorised the payment at the ASPSP).
Note: Volume of successful and failed payment initiations through PISP for payment orders requiring multi-authorisations. Note:
For the avoidance of doubt, this item refers to number of endpoint calls which resulted in the following conditions:
a. the payments consent resource in AwaitingAuthorisation state moved to Authorised state due to first authoriser PSU authorising the consent.
b. the multi authorisation object status moved from AwatingFurtherAuthorisation to Authorised due to all authoriser PSUs authorising the payment order.		 Max20AlphaNumericText Mandatory Integer number with value >=0 If endpoint is not a PIS endpoint, then value should be NULL. Conditions 1. Multi Auth API Calls Successful <= API Calls Authorised by PSUs
14 Multi Auth API Calls Failed (10.12) This is the number of PIS endpoint calls that required multiple authorisations and have failed to be fully authorised . This only applies to payment initiation. In the context of this template reporting, for multi-auth payments, a failed payment initiation occurs in circumstances where, after the first PSU has initiated a draft payment order using a PISP, the payment order is subsequently never completed due to other authorisers not authorising the payment within the timeframes (if any) of the multi authorisation process at the ASPSP.
Note: For the avoidance of doubt, this item refers to number of endpoint calls which resulted in the following conditions:
a. the payments consent resource in AwaitingAuthorisation state moved to Authorised state due to first authoriser PSU authorising the consent.
b. the multi authorisation object status moved from AwatingFurtherAuthorisation to Rejected due to one of the authoriser PSUs not authorising the payment order or any other reason for rejection within the ASPSP multi auth process.		 Max20AlphaNumericText Mandatory Integer number with value >=0
If endpoint is not a PIS endpoint, then value should be NULL.
Conditions
1. Multi Auth API Calls Successful <= API Calls Authorised by PSUs
15 Version The OBIE Standards version of the endpoint implementation by the ASPSP, aggregated at the level of major or minor release, as defined in item#10 of Section 1 key usage instructions. Max40Text Mandatory Allowed enumeration values:
v1.0, v1.1, v2.0, v3.0, v3.1,...

Notes:
The below diagram illustrates the relationship between the fields item#6, item#7, item#8, item#9 and item#11 of the Daily Volumes table, and provides numerical examples.
Daily Flow Volumes

# 3.8 Additional Metrics (OBIE)

# 3.8.1 Payment Status

TAB: 8.1 Additional Metrics - Payment Status

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportMonth Reported calendar month and year Max6Text Mandatory ^(Jan\|Feb\|Mar\|Apr\|May\|Jun\|Jul\|Aug\|Sep\|Oct\|Nov\|Dec)\-\d{2}$ (mmm-yy)
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Mandatory Integer value in range 9999. Will be extended as new Brands join Open Banking
3 Number of PISPs This is the number of individual PISPs initiating payments and checking their payment status. For the avoidance of doubt OBIE is looking to receive the number of discrete PISPs (grouped by TPP ID) and not the number of discrete SSAs onboarded with the ASPSP making the endpoint calls Number Mandatory Integer number with value >=0
4 Payment Status This is the status of the payment resource is returned by the response to the payment initiation endpoint call or the subsequent call to the GET endpoint. Note: This status is the terminal status of the resource, not a transitional one.
ASPSPs must only report on the listed status if it is one of the terminal states of the payment resource. For example, some ASPSPs consider ā€˜Pendingā€™ as a terminal state whereas some do not. Hence reporting on ā€˜Pendingā€™ status is enabled.		 Max40Text Mandatory Allowed enumeration values:
-Pending
-Rejected
-AcceptedSettlementInProcess
-AcceptedSettlementCompleted
-AcceptedCreditSettlementCompleted
5 Volume of Payments This is the total number of payments (payment resources) that have been checked for their status and returned a terminal status as defined in the Payment Status column. Max20AlphaNumericText Mandatory Integer number with value >=0

# 3.8.2 Payment SCA Exemptions

TAB: 8.2 Additional Metrics - Payment SCA Exemptions

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportMonth Reported calendar month and year Max6Text Mandatory ^(Jan\|Feb\|Mar\|Apr\|May\|Jun\|Jul\|Aug\|Sep\|Oct\|Nov\|Dec)\-\d{2}$ (mmm-yy)
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Mandatory Integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 Number of PISPs This is the number of individual PISPs initiating payments and checking their payment status. For the avoidance of doubt OBIE is looking to receive the number of discrete PISPs (grouped by TPP ID) and not the number of discrete SSAs onboarded with the ASPSP making the endpoint calls Number Mandatory Integer number with value >=0
4 Payment Exemption Requested This is the status of the payment resource is returned by the response to the payment initiation endpoint call or the subsequent call to the GET endpoint. Max40Text Mandatory Allowed enumeration values:
BillPayment
ContactlessTravel
EcommerceGoods
EcommerceServices
Kiosk Parking
PartyToParty
5 Volume of Payments requested SCA exemption This is the total number of payment initiation requests (payment consent endpoints) that have requested an SCA exemption by the PISP to the ASPSP, as per the SCA exemption stated in the Payment Exemption Requested column. Max20AlphaNumericText Mandatory Integer number with value >=0
6 Volume of Payments granted SCA exemption This is the total number of payment initiation requests (payment consent endpoints) that have requested an SCA exemption by the PISP to the ASPSP, as per the SCA exemption stated in the Payment Exemption Requested column and the ASPSPs have granted the SCA exemption request and did not apply SCA. Max20AlphaNumericText Mandatory Integer number with value >=0

# 3.8.3 Revocation Notifications from ASPSPs

TAB: 8.3 Additional Metrics - Revocation Notifications from ASPSPs

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportMonth Reported calendar month and year Max6Text Mandatory ^(Jan\|Feb\|Mar\|Apr\|May\|Jun\|Jul\|Aug\|Sep\|Oct\|Nov\|Dec)\-\d{2}$ (mmm-yy)
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Mandatory Integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 Number of AISPs This is the number of individual AISPs making polling API calls or receiving push notifications in order to check whether account access authorisation has taken place at the ASPSP. For the avoidance of doubt OBIE is looking to receive the number of discrete AISPs (grouped by TPP ID) and not the number of discrete SSAs onboarded with the ASPSP making the endpoint calls Number Mandatory Integer number with value >=0
4 Notification Method Used This is the various notification methods used by ASPSPs to notify AISPs that a PSU has revoked access via the Access Dashboard. Max40Text Mandatory Allowed enumeration values:
Basic Polling
Aggregated Polling
Push Notifications
Push Notifications Retries
5 Volume of Successful Notification of Revocation This is the total number of successful notification endpoint calls for the notification of revocation of access by PSUs, using the notification method as stated in the Notification Method Used column. Max20AlphaNumericText Mandatory Integer number with value >=0
6 Volume of Failed Notification of Revocation This is the total number of failed notification endpoint calls for the notification of revocation of access by PSUs, using the notification method as stated in the Notification Method Used column. Note: This would only be applicable to Basic Polling and Aggregated Polling. Max20AlphaNumericText Mandatory Integer number with value >=0 NULL when Notification Method Used is 'Push Notifications' or 'Push Notifications Retries'

# 3.8.4 AIS Corporate Account Access

TAB: 8.4 Additional Metrics - AIS Corporate Account Access (OPTIONAL)

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportMonth Reported calendar month and year Max6Text Optional ^(Jan\|Feb\|Mar\|Apr\|May\|Jun\|Jul\|Aug\|Sep\|Oct\|Nov\|Dec)\-\d{2}$ (mmm-yy)
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Optional Integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 Number of AISPs This is the number of individual AISPs requesting AIS access to corporate accounts. For the avoidance of doubt OBIE is looking to receive the number of discrete AISPs (grouped by TPP ID) and not the number of discrete SSAs onboarded with the ASPSP making the endpoint calls Number Optional Integer number with value >=0
4 Volume of Successful Corporate Account Access This is the total number of successful AIS consent requests (account access consent resources) that have been authorised as the PSU had authorisation by their Corporate to access the corporate accounts. Max20AlphaNumericText Optional Integer number with value >=0
5 Volume of Rejected Corporate Account Access This is the total number of rejected AIS consent requests (account access consent resources) that have not been authorised as the PSU did not have authorisation by their Corporate to access the corporate accounts. Max20AlphaNumericText Optional Integer number with value >=0

# 3.8.5 Payment Refunds

TAB: 8.5 Additional Metrics - Payment Refunds

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportMonth Reported calendar month and year Max6Text Mandatory ^(Jan\|Feb\|Mar\|Apr\|May\|Jun\|Jul\|Aug\|Sep\|Oct\|Nov\|Dec)\-\d{2}$ (mmm-yy)
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Mandatory Integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 Number of PISPs This is the number of PISPs requesting PSUs' account details to be provided by the ASPSPs as part of the payment journey, during the reporting period. For the avoidance of doubt OBIE is looking to receive the number of discrete PISPs (grouped by TPP ID) and not the number of discrete SSAs onboarded with the ASPSP making the endpoint calls. Number Mandatory Integer number with value >=0
4 Volume of payments with Synchronous Refund Information This is the volume of payments for which ASPSPs provided PSU's account details to the PISPs for refund purposes, during the reporting period. Max20AlphaNumericText Mandatory Integer number with value >=0

# 3.8.6 90-Days Re-authentication

TAB: 8.6 Additional Metrics - 90 Days Re-authentication

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportMonth Reported calendar month and year Max6Text Mandatory ^(Jan\|Feb\|Mar\|Apr\|May\|Jun\|Jul\|Aug\|Sep\|Oct\|Nov\|Dec)\-\d{2}$ (mmm-yy)
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Mandatory Integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 Number of AISPs This is the number of AISPs using the delegated 90-days re-authentication process during the reporting period. Number Mandatory Integer number with value >=0
4 Volume of successful re-authentications This is the volume of successful re authentications by PSUs generating access refreshes by ASPSPs. Max20AlphaNumericText Mandatory Integer number with value >=0
5 Volume of overdue re-authentications The volume of re-authentication overdue for renewal where the PSU did not re-authenticate. Max20AlphaNumericText Mandatory Integer number with value >=0

Note: These additional metrics are only used to report 90-days re-authentication done by AISPs using delegated SCA.

# 3.9 PSU Interface Performance and Availability (P & A)

TAB: 9 PSU interface P & A (OBIE)

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportDate Reported date for each calendar day ISODate Mandatory A particular point in the progression of time in a calendar year expressed in the YYYY-MM-DD format. This representation is defined in "XML Schema Part 2: Datatypes Second Edition - W3C Recommendation 28 October 2004" which is aligned with ISO 8601.
2 ASPSP Brand ID Reporting ASPSP Brand ID as defined in section 2.2. ASPSP Brand List. Number Mandatory Integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 PSU channel This is the various notification methods used by ASPSPs to notify AISPs that a PSU has revoked access via the Access Dashboard. Max40Text Mandatory Allowed enumeration values: Online Banking Mobile Banking
4 Core/Non Core Hours (8.4/8.5) Used for reporting the availability and performance of each PSU Channel during core hours (06.00-0.00) and non-core hours (0.00-06.00) of each calendar day Max40Text Mandatory Allowed enumeration values: - Core Hours (06.00 - 00.00) - Non Core Hours (00.00 - 06.00)
5 Uptime Uptime per each PSU Channel as a percentage of total seconds in the period of core (06:00 ā€“ 24.00) or non-core hours (00.00 ā€“ 06.00). Total uptime is calculated as: 1. Core Hours: Uptime = 100% - percentage of total downtime during core hours 2. Non-Core Hours: Uptime = 100% - percentage of total downtime during non-core hours Number Mandatory Conditions 1. Core Hours: Uptime + Downtime = 100% 2. Non-Core Hours: Uptime + Downtime = 100%
6 Downtime The total number of concurrent seconds per API call, per the hours in the period of core or and non-core hours, that any element of the dedicated interface is not available divided by the number of seconds in the period (i.e. 64,800 for core-hours and 21,600 for non-core hours) and expressed as a percentage. The clock for unavailability should start immediately after the service becomes unavailable. For the definition of unavailability, please refer to section 1.1.2. - PSU Interface Downtime Number Mandatory Conditions 1. Core Hours: Uptime + Downtime = 100% 2. Non-Core Hours: Uptime + Downtime = 100%

# 4. Physical Data Dictionary

# 4.1 Data Dictionary

Data dictionary provides detailed descriptions for each field in the message specification along with the associated code lists, constraints and other technical details such as cardinality, any pattern constraints, min, max length etc. It can be found here

# 4.2 Codelist

List of enumeration values which have been used in the API Specification can be found here.

# 4.3 MI Data JSON Schema

JSON Schema for MI Reporting Data format can be found here.

# 5. Example Reporting Template

An example of the Reporting Template, found here, can be used for the reporting of the data elements described in the Data Dictionary.

# 6. Appendix

# 6.1 Measuring Performance for AISP, PISP and CBPII (as defined in OBIE Operational Guidelines)

EBA Guideline 2.3 sets out a minimum of four KPIs for performance that an ASPSP should have in place for each of its dedicated interfaces. The following tables explain these KPIs in greater detail and provide guidance on how they should be calculated, as defined in OBIE Operational Guidelines. OBIE will be using the calculations shown below in order to produce Average Response times for PIS, AIS and CBPII CoF.

# 6.1.1 Payment Initiation

Sequence Diagram Description
Sequence Diagram Technical flow/PSU present:
Step 1: PISP consent stage
Step 2: Setup of Payment order consent:
- PISP initiates client credentials grant.
- (a) ASPSP validates identity of PISP to establish a secure connection and responds with access token.
- PISP submits payment request.
- (b) ASPSP responds with consent ID.
Step 3: Authorise Consent:
PISP redirects the PSU to the domain of the ASPSP for authentication.
- (c) ASPSP performs SCA, this can include account selection and supplementary information.
- (d) Once authentication is successfully completed, the ASPSP will send authorisation code to the PISP. PISP exchanges authorisation code.
- (e)The ASPSP responds with access token.
Step 4: COF (Optional for PISPs) ā€“ reported separately (GL 2.3 (c))
PISP requests COF.
- (f) ASPSP responds to COF request.
Step 5: Create Payment Order:
The PISP will submit the payment order.
- (g) ASPSP send all information to the PISP relating to the payment order (Reg. 69(2)(b)).
Optional:
Step 6: Get Payment Order Consent
PISP requests payment status
- (h) ASPSP responds with payment status.
EBA requirement OBIE calculations
EBA Guideline 2.3 (a)
ā€¦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;		 1. Average PIS response time = Avg Ta+Avg Tb+Avg Td+Avg Te+Avg Tg (Mandatory)
2. Average PSU authentication time = Avg Tc = (Tc) / (Vc) (Optional)
3. Average PIS Y/N confirmation = Avg Tf = (Tf) / (Vf) (Separate Reporting)
4. Average PIS status response = Avg Th = (Th) / (Vh) (Separate Reporting)

Avg Ta & Avg Te: Average Time Periods a & e
The following OIDC endpoints should be reported to be included in the calculation for the response time of time periods Ta & Te:
- OIDC endpoints for token IDs
The average response time of all endpoints in time periods Ta & Te shown above should be calculated as follows:
Avg Ta = Avg Te = (Ta & Te) / (Va & e)
where Va & e is the total volume of calls made to the end-points listed for time periods Ta & Te

Avg Tb: Average Time Period b
The following API endpoints relevant to the payment consent staging should be included in the calculation for the response time of time period Tb:
- POST /domestic-payment-consents
- POST /domestic-scheduled-payment-consents
- POST /domestic-standing-order-consents
- POST /international-payment-consents
- POST /international-scheduled-payment-consents
- POST /international-standing-order-consents
- POST /file-payment-consents
- POST /file-payment-consents/{ConsentId}/file
The average response time of all endpoints shown above should be calculated as follows:
Avg Tb = (Tb) / (Vb)
where, Vb is the total volume of calls made to the end-points listed for time period Tb
Please note that in the case of payment staging API endpoints from the above list (i.e. POST endpoints), the response time must include ā€œthe time it takes for any checks that the ASPSP may choose to make on the authorisation/registration of TPPsā€. This may include validation of access token, validation of the request payload, authentication/validation of the request etc.

Avg Tc: Average Time Period c
PSU Authentication time (PSU involvement) (OPTIONAL)
This is the total time taken for the PSU to complete the authentication process. For the avoidance of doubt, this is the time measured in seconds from the point in time the PSU, after being redirected to the authentication screen of the ASPSP Authorisation Server, submits the credentials for authentication, completes authentication and any other actions such as selecting account(s), until control is passed back to the ASPSP to start the process of generating the authorisation code.
The average response time of all endpoints shown above should be calculated as follows:
Avg Tc = (Tc) / (Vc)
where, Vc is the total volume of PSU authentications that generated the total response time Tc

Avg Td: Average Time Period d
The following is not an OIDC endpoint as such but it is an entry to be used for measuring the time period (d) of the authorisation code generation by ASPSPs:
- Generated OIDC Authorisation code
The average response time of all endpoints shown above should be calculated as follows:
Avg Td = (Td) / (Vd)
where, Vd is the total volume of calls made to the end-points listed for time period Td

Avg Tf: Average Time Period f
The following API endpoints relevant to the payment consent staging should be included in the calculation for the response time of time period Tf:
- GET /domestic-payment-consents/{ConsentId}/funds-confirmation
- GET /international-payment-consents/{ConsentId}/funds-confirmation
- GET /international-scheduled-payment-consents/{ConsentId}/funds-confirmation
The average response time of all endpoints shown above should be calculated as follows:
Avg Tf = (Tf) / (Vf)
where, Vf is the total volume of calls made to the end-points listed for time period Tf

Avg Tg: Average Time Period g
The following API endpoints relevant to the payment consent staging should be included in the calculation for the response time of time period Tg

- POST /domestic-payments
- POST /domestic-scheduled-payments
- POST /domestic-standing-orders
- POST /international-payments
- POST /international-scheduled-payments
- POST /international-standing-orders
- POST /file-payments
The average response time of all endpoints shown above should be calculated as follows:
Avg Tg = (Tg) / (Vg)
where, Vg is the total volume of calls made to the end-points listed for time period Tg

Avg Th: Average Time Period h
The following API endpoints relevant to the payment consent staging should be included in the calculation for the response time of time period Th:
- GET /domestic-payments/{DomesticPaymentId}
- GET /domestic-payments/{DomesticPaymentId}/payment-details
- GET /domestic-scheduled-payments/{DomesticScheduledPaymentId}
- GET /domestic-scheduled-payments/{DomesticScheduledPaymentId}/payment-details
- GET /domestic-standing-orders/{DomesticStandingOrderId
- GET /domestic-standing-orders/{DomesticStandingOrderId}/payment-details
- GET /international-payments/{InternationalPaymentId}
- GET /international-payments/{InternationalPaymentId}/payment-details
- GET /international-scheduled-payments/{InternationalScheduledPaymentId}
- GET /international-scheduled-payments/{InternationalScheduledPaymentId}/payment-details
- GET /international-standing-orders/{InternationalStandingOrderPaymentId}
- GET /international-standing-orders/{InternationalStandingOrderPaymentId}/payment-details
- GET /file-payments/{FilePaymentId}
- GET /file-payments/{FilePaymentId}/report-file
- GET /file-payments/{FilePaymentId}/payment-details
The average response time of all endpoints shown above should be calculated as follows:
Avg Th = (Th) / (Vh)
where, Vh is the total volume of calls made to the end-points listed for time period Th

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.

# 6.1.2 Account Information

Sequence Diagram Description
AISP Response Time Technical flow/PSU present:
- Step 1: AISP consent stage
- Step 2 - Setup of Account Access consent:
- AISP initiates client credentials grant.
- (a) ASPSP validates identity of AISP to establish a secure connection and responds with access token.
- AISP submits the Account Access consent request.
- (b) ASPSP responds with consent ID.
Step 3: Authorise Consent:
- AISP redirects the PSU to the domain of the ASPSP for authentication.
- (c) ASPSP performs SCA, this will include account selection.
- (d) Once authentication is successfully completed, the ASPSP will send authorisation code to the AISP.
- AISP exchanges authorisation code.
- (e)The ASPSP responds with access token.
Step 4: Request Data:
- AISP requests list of authorised accounts.
- (f) ASPSP responds with a list of authorised accounts and IDs.
- AISP requests account information data either per account or in bulk.
- (g) ASPSP responds with account information data
EBA requirement OBIE calculations
EBA Guideline 2.3 (b)
ā€¦the ASPSP should define, at a minimum, the following KPIs for the performance of the dedicated interface:
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;		 1. Average AIS response time = (Ta+Tb+Td+Te+Tf+Tg) / (Vg) (Mandatory)
2. Average PSU authentication time = Tc Avg = (Tc) / (Vc) (Optional)

Ta & Te: Time Periods a & e
The following OIDC endpoints should be reported to be included in the total response time:
- OIDC endpoints for token IDs
Where an ASPSP cannot seperate calls to the OIDC token endpoint based it the scope parameter, the ASPSP should apportion the total OIDC calls in the same ratio as AIS, PIS and CBPII consents.
Tb: Time Period b
The following API endpoints relevant to the account access consent staging should be included when calculating AISP response times:
- POST /account-access-consents
Please note that in the case of account information consent staging API endpoints from the above list (i.e. POST endpoints), the response time must include ā€œthe time it takes for any checks that the ASPSP may choose to make on the authorisation/registration of TPPsā€. This may include validation of access token, validation of the request payload, authentication/validation of the request etc.

Avg Tc: Average Time Period c
PSU Authentication time (PSU involvement) (OPTIONAL)
This is the total time taken for the PSU to complete the authentication process. For the avoidance of doubt, this is the time measured in seconds from the point in time the PSU, after being redirected to the authentication screen of the ASPSP Authorisation Server, submits the credentials for authentication, completes authentication and any other actions such as selecting account(s), until control is passed back to the ASPSP to start the process of generating the authorisation code.
The average response time of all endpoints shown above should be calculated as follows:
Avg Tc = (Tc) / (Vc)
where, Vc is the total volume of PSU authentications that generated the total response time Tc

Td: Time Period d
The following is not an OIDC endpoint as such but it is an entry to be used for measuring the time period (d) of the authorisation code generation by ASPSPs.
- Generated OIDC Authorisation code
Where an ASPSP cannot seperate calls to the OIDC token endpoint based it the scope parameter, the ASPSP should apportion the total OIDC calls in the same ratio as AIS, PIS and CBPII consents.

Tf: Time Period f
- GET /accounts

Tg: Time Period g
- 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

Vg: Volume of calls g
Total volume of calls made to the end-points listed in Tg

# 6.1.3 Confirmation of Funds for CBPII

Sequence Diagram Description
CBPII Response Times Technical flow/PSU present:
- Step 1: CBPII CoF consent stage
- Step 2 - Setup of CBPII CoF Access consent:
- CBPII initiates client credentials grant.
- (a) ASPSP validates identity of CBPII to establish a secure connection and responds with access token.
- CBPII submits the CoF Access consent request.
- (b) ASPSP responds with consent ID.
- Step 3: Authorise Consent:
- CBPII redirects the PSU to the domain of the ASPSP for authentication.
- (c) ASPSP performs SCA, this will include providing consent.
- (d) Once authentication is successfully completed, the ASPSP will send authorisation code to the CBPII.
- CBPII exchanges authorisation code.
- (e)The ASPSP responds with access token.
- Step 4: Request CoF Response:
- CBPII requests CoF response for amount
- (f) ASPSP responds with a Y/N response to the CoF request for the amount
EBA requirement OBIE calculations
EBA Guideline 2.3 (c)
ā€¦the ASPSP should define, at a minimum, the following KPIs for the performance of the dedicated interface:
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;		 - Average CBPII CoF response time = (Ta+Tb+Td+Te+Tf) / (Vf) (Mandatory)
- Average PSU authentication time = Avg Tc = (Tc) / (Vc) (Optional)

Time Periods a & e
The following OIDC endpoints should be reported to be included in the total response time:
- OIDC endpoints for token IDs
Where an ASPSP cannot separate calls to the OIDC token endpoint-based it the scope parameter, the ASPSP should apportion the total OIDC calls in the same ratio as AIS, PIS and CBPII consents.

Time Period b
The following API endpoints relevant to the CBPII CoF access consent staging should be included when calculating CBPII response times:
- POST /funds-confirmation-consents
- Please note that in the case of CBPII CoF consent staging API endpoints from the above list (i.e. POST endpoints), the response time must include ā€œthe time it takes for any checks that the ASPSP may choose to make on the authorisation/registration of TPPsā€. This may include validation of access token, validation of the request payload, authentication/validation of the request etc.

Avg Tc: Average Time Period c
PSU Authentication time (PSU involvement) (OPTIONAL)
This is the total time taken for the PSU to complete the authentication process. For the avoidance of doubt, this is the time measured in seconds from the point in time the PSU, after being redirected to the authentication screen of the ASPSP Authorisation Server, submits the credentials for authentication, completes authentication and any other actions such as providing consent, until control is passed back to the ASPSP to start the process of generating the authorisation code.
The average response time of all endpoints shown above should be calculated as follows:
Avg Tc = (Tc) / (Vc)
where Vc is the total volume of PSU authentications that generated the total response time Tc

Time Period d
The following is not an OIDC endpoint as such but it is an entry to be used for measuring the time period (d) of the authorisation code generation by ASPSPs.
- Generated OIDC Authorisation code
Where an ASPSP cannot separate calls to the OIDC token endpoint-based on the scope parameter, the ASPSP should apportion the total OIDC calls in the same ratio as AIS, PIS and CBPII consents.

Time Period f
- POST /funds-confirmations

Vf: Volume of calls f
Total volume of calls made to the end-points listed in Tf

# 7. Version control

Version Date Authors Comments
V0.1 30 Nov 2020 OBIE API Delivery Team The final version, further to IESG approval
V0.2 16 Dec 2020 OBIE API Delivery Team Updated version, prior to IESG approval
V0.3 24 Dec 2020 OBIE API Delivery Team Updated version, prior to Jan TDA