MI Reporting Data API Specification

• 1. Reporting Template Key Usage Instructions
  • 1.1 Unavailability Definition (Downtime)
• 2. Predefined Lists
  • 2.1 API Endpoint List
  • 2.2. ASPSP Brand List
• 3. Logical Data Dictionary
  • 3.1 Performance and Availability (P & A)
  • 3.1-A PSU Authentication & Interaction (OPTIONAL)
  • 3.2 Response Outliers (OBIE)
  • 3.3 Auth Efficacy (OBIE)
  • 3.4 PSU Adoption (OBIE)
  • 3.4-A Enhanced PSU Adoption (OBIE)
  • 3.4-B PSU Consent Adoption (OBIE)
  • 3.5 Payments Adoption (OBIE)
  • 3.6 TPP Volumes (OBIE)
  • 3.7 Daily Volumes (OBIE)
  • 3.8 Additional Metrics (OBIE)
  • 3.9 PSU Interface Performance and Availability (P & A)
• 4. Physical Data Dictionary
  • 4.1 Data Dictionary
  • 4.2 Codelist
  • 4.3 MI Data JSON Schema
• 5. Example Reporting Template
• 6. Appendix
  • 6.1 Measuring Performance for AISP, PISP and CBPII (as defined in OBIE Operational Guidelines)
• 7. Version control

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 L (Confirmation Required), M (Confirmation Accepted by PSUs) and N (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 Re-authentication of 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 .

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	N/A
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	N/A
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	N/A
58	file-payments	GET /file-payments/{FilePaymentId}	PISP	Mandatory (if resource POST implemented)	Payments - Bulk/Batch Payments	N/A
59	file-payments	GET /file-payments/{FilePaymentId}/report-file	PISP	Conditional	Payments - Bulk/Batch Payments	N/A
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
93	domestic-vrp-consents	POST /domestic-vrp-consents	PISP	Mandatory	Payments - Domestic Variable recurring payments Consent	N/A
94	domestic-vrp-consents	GET /domestic-vrp-consents/{ConsentId}	PISP	Mandatory (if resource POST implemented	Payments - Domestic Variable recurring payments status	N/A
95	domestic-vrp-consents	DELETE /domestic-vrp-consents/{ConsentId}	PISP	Mandatory (if resource POST implemented	Payment - Delete Variable recurring payment Consent	N/A
96	domestic-vrp-consents	POST /domestic-vrp-consents/{ConsentId}/funds-confirmation	PISP	Mandatory (if resource POST implemented	Payments -Confirmation of Funds	N/A
97	domestic-vrps	POST /domestic-vrps	PISP	Conditional	Payments -Domestic Variable recurring payments	N/A
98	domestic-vrps	GET /domestic-vrps/{DomesticVRPId}	PISP	Conditional	Payments - Domestic Variable recurring payment status	N/A
99	domestic-vrps	GET /domestic-vrps/{DomesticVRPId}/payment-details	PISP	Optional	Payments - Domestic Variable recurring payment status detail	N/A
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.)
2. For further clarifications, please refer to the following diagram (kindly provided by Barclays):
   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
10	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
11	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
12	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
13	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
14	Total number of PSUs used both Mobile Banking and Online Banking	The total number of unique PSUs (customers with one or more accounts with the ASPSP brand) who: a. have used the Online Banking service for either accessing account information or initiating a payment. AND b. 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 Online Banking and Mobile Banking <= Total number of PSUs used Mobile Banking + Total number of PSUs used Online 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) Note: PSU is considered active if they have at least one active long-lived consent at the time of reporting. The PSU should be counted only once under any of the above category. E.g 1: PSU has given consent for 'x' months to a AISP and has initiated a payment with another PISP in the reporting month then the PSU should be counted once under AIS_&_PIS. E.g. 2: PSU should not be counted if the PSU has given consent for 'x' months to a AISP in a reporting month however the PSU has also revoked the same consent at the TPP in the same reporting month.	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 (i.e. the number of SME business 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 only the relevant API Service selected under #4: - 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 only the relevant API Service selected under #4: - all consents which are active at the beginning of the reporting period. - account-access-consent resources or funds-confirmation-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 at the TPP during the reporting period. For the avoidance of doubt this refers to only the relevant API Service selected under #4 i.e. account-access-consent resources or funds-confirmation-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. For the avoidance of doubt this refers to only the relevant API Service selected under #4 i.e. account-access-consent resources or funds-confirmation-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 re-authentication, as per the PSR 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. Note: This does not apply to funds-confirmation-consent resources	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 and have been 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. This does not apply to funds-confirmation-consent resources	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 only the relevant API Service selected under #4 i.e. account-access-consent resources or funds-confirmation-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 only the relevant API Service selected under #4 i.e.: - 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 - funds-confirmation-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 + New consents
13	Long-lived consents - Total Refreshed consents	This is the total number of unique Long-lived consents which have been 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. This does not apply to funds-confirmation-consent resources	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.
• Plus new consents.
• Outstanding consents at end of reporting period (EoP)
  Additional Note:
  This table must not include any VRP resources.

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. Note: To include payments that were successfully initiated(Status=AcceptedSettlementCompleted) but transitioned to successfully executed (Status=AcceptedCreditSettlementCompleted) while reporting.	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. Note: To count only once and those end point calls that resulted in the status of the underlined resource in ‘Rejected’ state. e.g. status of account access consent or payment consent marked as ‘Rejected’ due to PSU taking action of rejecting during authorisation.	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(abandoned the journey). Note: The item refers to the number of endpoint calls which resulted in: a. payments consent resources in AwaitingAuthorisation state that are either in the same ‘AwaitingAuthorisation’ state (final state) or moved to Rejected state due to PSU not authorising the consent. b. account access consent resources in AwaitingAuthorisation state that are either in the same ‘AwaitingAuthorisation’ state (final state) or moved to Rejected state due to due to PSU not authorising the consent. c. funds-confirmation-consent resources in AwaitingAuthorisation state that are either in the same ‘AwaitingAuthorisation’ state (final state) or 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.

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.8.7 Variable Recurring Payments (VRPs)

TAB: 8.7 Additional Metrics - VRP

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	Category of VRP	Type of VRP Consent	Max40Text	Mandatory		Allowed enumeration values Sweeping Non Sweeping
4	Number of PISPs	This is the total number of PISPs setup VRP Consent for the first time per the category of VRP, in the reporting period.	Number	Mandatory		Integer number with value >=0
5	Volume of successful VRP Consents	This is the total number of VRP consents requiring authentication per the category of VRP, by the PSU and the authentication have succeeded in the reporting period.	Max20AlphaNumericText	Mandatory		Integer number with value >=0
6	Volume of failed VRP Consents	This is the total volume of VRP consents requiring authentication by the PSU per the category of VRP, and the authentication have failed in the reporting period.	Max20AlphaNumericText	Mandatory		Integer number with value >=0
7	Volume of revoked VRP access	This is the total volume of unique Long-lived Variable recurring payment access which have been revoked by PSUs per category of VRP, during the reporting period.	Max20AlphaNumericText	Mandatory		Integer number with value >=0
8	Volume of successful VRP payments	This is the total volume of successful payments per category of VRP in the reporting period.	Max20AlphaNumericText	Mandatory		Integer number with value >=0
9	Volume of failed VRP payments	This is the total volume of failed payments per category of VRP in the reporting period.	Max20AlphaNumericText	Mandatory		Integer number with value >=0
10	Volume of failed VRP payments -TB exempt	This is the total volume of VRP payments for sweeping where the ASPSP decided the Trusted Beneficiary Exemption could not be applied	Max20AlphaNumericText	Mandatory		Integer number with value >=0

Note: Mandatory for Sweeping. Mandatory for non-sweeping (VRP) if implemented.

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

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 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. 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 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 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. 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 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 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

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

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	14 Feb 2022	API Delivery Team	Initial draft for Industry consultation
V0.2	15 Mar 2022	API Delivery Team	Final for TDA approval
V0.2 (Final)	25 Mar 2022	API Delivery Team	Final for IESG approval