MI Reporting Data API Specification v3.1.2

• 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.2 Response Outliers (OBIE)
  • 3.3 Auth Efficacy (OBIE)
  • 3.4 PSU 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 UML Diagram
  • 4.2 Data Dictionary
  • 4.3 Codelist
  • 4.4 MI Data JSON Schema
• 5 Example Reporting Template
• 6. Version control

1. Reporting Template Key Usage Instructions

• For v3.1.2 functionality, ASPSPs must start submitting MI Data to OBIE using this template on the following month after going live with any of the v3.1.2 specifications functionality. The submission date of the month is defined in the SLA document. For any other reporting data or changes to the reporting calculations (such as Trustee Nov-18 MI Data or alignment with OGs) that are defined in the proposition paper v3.1.2 MI Requirements for ASPSPs - DRAFT 1, ASPSPs must report using this template under the timelines defined in the proposition paper section 8.1.
• ASPSPs must populate the template using the API Endpoint IDs as defined in the section 3.1 API Endpoint List
• ASPSPs must populate the template using the ASPSP Brand IDs as defined in the section 3.2 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 4
• 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 response 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 2.1
• For the avoidance of doubt, in tab 3. Auth Efficacy (OBIE), fields M (Confirmation Required), N (Confirmation Accepted by PSUs) and O (Confirmation Rejected by PSUs) relate only to journey's that require and additional confirmation step at the ASPSP side, as per the journeys defined in the CEG. Thus, single journeys 3.1.2, 4.1.1 are excluded together with any other case where other journeys defined in the CEG 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 4 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 v3.1.2 MI Requirements for ASPSPs.

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 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 effects the 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 during each day.
• Even if this only effects some 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 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 2.2.1: "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	Endpoint category	Endpoint name	Service
0	OIDC	OIDC endpoints for token IDs	OIDC
1	account-access-consents	POST /account-access-consents	AISP
2	account-access-consents	GET /account-access-consents/{ConsentId}	AISP
3	account-access-consents	DELETE /account-access-consents/{ConsentId}	AISP
4	accounts	GET /accounts	AISP
5	accounts	GET /accounts/{AccountId}	AISP
6	balances	GET /accounts/{AccountId}/balances	AISP
7	balances	GET /balances	AISP
8	transactions	GET /accounts/{AccountId}/transactions	AISP
9	transactions	GET /transactions	AISP
10	beneficiaries	GET /accounts/{AccountId}/beneficiaries	AISP
11	beneficiaries	GET /beneficiaries	AISP
12	direct-debits	GET /accounts/{AccountId}/direct-debits	AISP
13	direct-debits	GET /direct-debits	AISP
14	standing-orders	GET /accounts/{AccountId}/standing-orders	AISP
15	standing-orders	GET /standing-orders	AISP
16	products	GET /accounts/{AccountId}/product	AISP
17	products	GET /products	AISP
18	offers	GET /accounts/{AccountId}/offers	AISP
19	offers	GET /offers	AISP
20	party	GET /accounts/{AccountId}/party	AISP
21	party	GET /party	AISP
22	scheduled-payments	GET /accounts/{AccountId}/scheduled-payments	AISP
23	scheduled-payments	GET /scheduled-payments	AISP
24	statements	GET /accounts/{AccountId}/statements	AISP
25	statements	GET /accounts/{AccountId}/statements/{StatementId}	AISP
26	statements	GET /accounts/{AccountId}/statements/{StatementId}/file	AISP
27	statements	GET /accounts/{AccountId}/statements/{StatementId}/transactions	AISP
28	statements	GET /statements	AISP
29	domestic-payment-consents	POST /domestic-payment-consents	PISP
30	domestic-payment-consents	GET /domestic-payment-consents/{ConsentId}	PISP
31	domestic-payments	POST /domestic-payments	PISP
32	domestic-payments	GET /domestic-payments/{DomesticPaymentId}	PISP
33	domestic-scheduled-payment-consents	POST /domestic-scheduled-payment-consents	PISP
34	domestic-scheduled-payment-consents	GET /domestic-scheduled-payment-consents/{ConsentId}	PISP
35	domestic-scheduled-payments	POST /domestic-scheduled-payments	PISP
36	domestic-scheduled-payments	GET /domestic-scheduled-payments/{DomesticScheduledPaymentId}	PISP
37	domestic-standing-order-consents	POST /domestic-standing-order-consents	PISP
38	domestic-standing-order-consents	GET /domestic-standing-order-consents/{ConsentId}	PISP
39	domestic-standing-orders	POST /domestic-standing-orders	PISP
40	domestic-standing-orders	GET /domestic-standing-orders/{DomesticStandingOrderId}	PISP
41	international-payment-consents	POST /international-payment-consents	PISP
42	international-payment-consents	GET /international-payment-consents/{ConsentId}	PISP
43	international-payments	POST /international-payments	PISP
44	international-payments	GET /international-payments/{InternationalPaymentId}	PISP
45	international-scheduled-payment-consents	POST /international-scheduled-payment-consents	PISP
46	international-scheduled-payment-consents	GET /international-scheduled-payment-consents/{ConsentId}	PISP
47	international-scheduled-payments	POST /international-scheduled-payments	PISP
48	international-scheduled-payments	GET /international-scheduled-payments/{InternationalScheduledPaymentId}	PISP
49	international-standing-order-consents	POST /international-standing-order-consents	PISP
50	international-standing-order-consents	GET /international-standing-order-consents/{ConsentId}	PISP
51	international-standing-orders	POST /international-standing-orders	PISP
52	international-standing-orders	GET /international-standing-orders/{InternationalStandingOrderPaymentId}	PISP
53	file-payment-consents	POST /file-payment-consents	PISP
54	file-payment-consents	GET /file-payment-consents/{ConsentId}	PISP
55	file-payment-consents	POST /file-payment-consents/{ConsentId}/file	PISP
56	file-payment-consents	GET /file-payment-consents/{ConsentId}/file	PISP
57	file-payments	POST /file-payments	PISP
58	file-payments	GET /file-payments/{FilePaymentId}	PISP
59	file-payments	GET /file-payments/{FilePaymentId}/report-file	PISP
60	funds-confirmation-consent	POST /funds-confirmation-consents	CoF
61	funds-confirmation-consent	GET /funds-confirmation-consents/{ConsentId}	CoF
62	funds-confirmation-consent	DELETE /funds-confirmation-consents/{ConsentId}	CoF
63	funds-confirmation	POST /funds-confirmations	CoF
64	payments	POST /payments	PIS
65	payments	GET /payments/{PaymentId}	PIS
66	payment-submissions	POST /payment-submissions	PIS
67	payment-submissions	GET /payment-submissions/{PaymentSubmissionId}	PIS
68	account-requests	POST /account-requests	AIS
69	account-requests	GET /account-requests/{AccountRequestId}	AIS
70	account-requests	DELETE /account-requests/{AccountRequestId}	AIS
71	Callback-url	POST /callback-urls	Notifications
72	Callback-url	GET /callback-urls	Notifications
73	Callback-url	PUT /callback-urls/{CallbackUrlId}	Notifications
74	Callback-url	DELETE /callback-urls/{CallbackUrlId}	Notifications
75	domestic-payment-consents	GET /domestic-payment-consents/{ConsentId}/funds-confirmation	CoF
76	international-payment-consents	GET /international-payment-consents/{ConsentId}/funds-confirmation	CoF
77	international-scheduled-payment-consents	GET /international-scheduled-payment-consents/{ConsentId}/funds-confirmation	CoF
78	party	GET /accounts/{AccountId}/parties	AISP
79	domestic-payments	GET /domestic-payments/{DomesticPaymentId}/payment-details	PISP
80	domestic-scheduled-payments	GET /domestic-scheduled-payments/{DomesticScheduledPaymentId}/payment-details	PISP
81	domestic-standing-orders	GET /domestic-standing-orders/{DomesticStandingOrderId}/payment-details	PISP
82	international-payments	GET /international-payments/{InternationalPaymentId}/payment-details	PISP
83	international-scheduled-payments	GET /international-scheduled-payments/{InternationalScheduledPaymentId}/payment-details	PISP
84	international-standing-orders	GET /international-standing-orders/{InternationalStandingOrderPaymentId}/payment-details	PISP
85	file-payments	GET /file-payments/{FilePaymentId}/payment-details	PISP
86	Event Notification Subscriptions	POST /event-subscriptions	Notifications
87	Event Notification Subscriptions	GET /event-subscriptions	Notifications
88	Event Notification Subscriptions	PUT /event-subscriptions/{EventSubscriptionId}	Notifications
89	Event Notification Subscriptions	DELETE /event-subscriptions/{EventSubscriptionId}	Notifications
90	Real-time Event Notifications	POST /event-notifications	Notifications
91	Aggregated Polling Notifications	POST /events	Notifications
9999	Other Endpoint code	Other End point code	General

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.

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
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	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 tab 'C. ASPS Brand List'	Number	Mandatory		Integer value in range 1-16. Will be extended as new Brands join Open Banking
3	Endpoint ID	Reported EndPoint ID as defined in tab tab 'B. Endpoint List' Note: ASPSPs must only report endpoints that have gone live in their systems.	Number	Mandatory		Integer value in range 1-70. 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 response 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 2.1.1 Total uptime is calculated as: 1. Core Hours: Uptime = Total number of core hours (18:00) - Total Planned Downtime (hh:ss) - Total Unplanned Downtime (hh:ss) 2. Non-Core Hours: Uptime = Total number of non-core hours (6:00) - Total Planned Downtime (hh:ss) - Total Unplanned Downtime (hh:ss)	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 2.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 2.1.1). The clock for unavailability should start as defined in section 2.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. 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. 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) 1.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 major or minor release, as defined in item#10 of Section 2 key usage instructions.	Max40Text	Mandatory		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 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 tab 'C. ASPS Brand List'	Number	Mandatory		Integer value in range 1-16. Will be extended as new Brands join Open Banking
4	Endpoint ID	Reported EndPoint ID as defined in tab tab 'B. Endpoint List' Note: ASPSPs must only report endpoints that have gone live in their systems.	Number	Mandatory		Integer value in range 1-70. 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
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 major or minor release, as defined in item#10 of Section 2 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 tab 'C. ASPS Brand List'	Number	Mandatory		Integer value in range 1-16. 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 this 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
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 requiring 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 requiring authentication that have 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).	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 2, 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 2, 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 2, 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 major or minor release, as defined in item#10 of Section 2 key usage instructions.	Max40Text	Mandatory		Allowed enumeration values: v1.0, v1.1, v2.0, v3.0, v3.1,...

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 tab 'C. ASPS Brand List'	Number	Mandatory		Integer value in range 1-16. 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.	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.	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 Total PSUs used AIS Services) 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 Conditions 1. Total PSUs used AIS Services >= PSUs used AIS Services for the first time
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 Total PSUs used PIS Services) 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.	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 Total PSUs used AIS Services) 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 Total PSUs used PIS Services) e. have authorised a payment initiation of any type from any of their account(s) via one or more PISPs during the reporting period and have initiated payments using PIS services before. For the avoidance of doubt: i. For AIS, a PSU in case (c) re-authenticating their account access should not be double counted if an AISP accesses their account after re-authentication. For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately. ii. For PIS, a PSU initiating a payment (e.g. single domestic) using a PISP A from a PCA A and then initiating another payment of different type (e.g. international) using a PISP B from a PCA B within the same ASPSP brand, should not be double counted. For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately.	Number	Mandatory		Integer number with value >=0 Conditions 1. Total unique PSUs used both AIS and PIS Services >= Unique PSUs used both AIS and PIS Services for the first time 2. Total unique PSUs used both AIS and PIS Services >= Total PSUs used AIS Services 3. Total unique PSUs used both AIS and PIS Services >= Total PSUs used PIS Services 4. Total unique PSUs used PIS Services <= Total PSUs used AIS Services + Total PSUs used PIS Services
11	Total new PSUs for Online Banking	The number of unique PSUs (customers with one or more accounts with the ASPSP brand) who have been granted access to the Online Banking for the first time.	Number	Mandatory		Integer number with value >=0
12	Total new PSUs for Mobile Banking	The number of unique PSUs (customers with one or more accounts with the ASPSP brand) who have been granted access to the Mobile Banking for the first time.	Number	Mandatory		Integer number with value >=0
13	Total number of PSUs used Online Banking	The total number of unique PSUs (customers with one or more accounts with the ASPSP brand) who have used the Online Banking service for either accessing account information or initiating a payment. Note: For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately.	Number	Mandatory		Integer number with value >=0 Conditions 1. Total number of PSUs used Online Banking >= Total new PSUs for Online Banking
14	Total number of PSUs used Mobile Banking	The total number of unique PSUs (customers with one or more accounts with the ASPSP brand) who have used the Mobile Banking service for either accessing account information or initiating a payment. Note: For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately.	Number	Mandatory		Integer number with value >=0 Conditions 1. Total number of PSUs used Mobile Banking >= Total new PSUs for Mobile Banking
15	Version	The OBIE Standards version of the implementation by the ASPSP, aggregated at the level of major or minor release, as defined in item#10 of Section 2 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.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 tab 'C. ASPS Brand List'	Number	Mandatory		Integer value in range 1-16. 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: It is not required to cover faster payments under this tab. The reason for this is that the number of faster payments can be derived from the overall daily volumetrics, subtracting the number of CHAPS and the Bacs payments, as the single Domestic Payments API endpoint call can be either one of these 3. For future dated payments (Domestic Scheduled and International Scheduled), there are different endpoints in the volumetrics tab, so again there is no need to cover these in this tab. For Standing Orders (both Domestic Standing Orders and International Standing Orders), the endpoint volumes are only providing the SOs setup instructions and there is no visibility of the actual number of SOs that will be generated. However, the MI requirements paper does not cover this, (it was initially included in earlier versions of the paper but was later dropped due to the scope reduction) so there is no justification at the moment to include this information.	Max40Text	Mandatory		Allowed enumeration values: - Bacs - CHAPS - Bulk - International
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, excluding the default payment type which is Faster Payments. Thus, this item relates only to Bacs and CHAPS single payments. 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
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, excluding the default payment type which is Faster Payments. Thus, this item relates only to Bacs and CHAPS single payments. Note: OBIE is focusing on the initiation of the payments and less the actual core banking transactions outcome. Thus for this item, OBIE is looking to receive the number of payment order calls (POST /domestic-payments endpoint calls) which resulted in domestic-payment resources with state AcceptedSettlementInProgress or AcceptedSettlementCompleted. This means that as a minimum, all preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution. This also assumes that that the payment order consent was also successful and has been authorised and consumed.	Max20AlphaNumericText	Mandatory		Integer number with value >=0 If payment type is Bulk: NULL If payment type is International: NULL Conditions 1. Successful single Domestic Payments <= PSU Authorisations for single Domestic Payments
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, excluding the default payment type which is Faster Payments. Thus, this item relates only to Bacs and CHAPS single payments. Note: OBIE is looking to receive the failed 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.	Max20AlphaNumericText	Mandatory		Integer number with value >=0 If payment type is Bulk: NULL If payment type is International: NULL
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, excluding the default payment type which is Faster Payments. Thus, this item relates only to Bacs and CHAPS single payments. Note: OBIE is looking to receive the failed 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.	Max20AlphaNumericText	Mandatory		Integer number with value >=0 If payment type is Bulk: NULL If payment type is International: NULL
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, excluding the default payment type which is Faster Payments. Thus, this item relates only to Bacs and CHAPS single payments. 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. Thus, the item refers to the number of these calls which resulted in: a. domestic payments consent resources in rejected state due to authorisation failing or consent authorisation being rejected b. domestic-payment resources in 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 payment type is Bulk: NULL If 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
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 payment type is Bacs: NULL If payment type is CHAPS: NULL If payment type is International: 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 value between 0% and 100% If payment type is Bacs: NULL If payment type is CHAPS: NULL If payment type is Bulk: NULL
11	Version	The OBIE Standards version of the implementation by the ASPSP, aggregated at the level of major or minor release, as defined in item#10 of Section 2 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 tab 'C. ASPS Brand List'	Number	Mandatory		Integer value in range 1-16. Will be extended as new Brands join Open Banking
3	Total AISPs Registered (at 1st of 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 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 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 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 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 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 month) = Cumulative Monthly number of CBPIIs (as reported on previous reported month)
12	CBPII Additions	This is the number of CBPIIs that have been on-boarded into 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 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 month) 2. Cumulative Monthly number of CBPIIs= Total CBPIIs Registered (at 1st of month) + CBPII Additions + CBPII Deregistrations
15	Version	The OBIE Standards version of the implementation by the ASPSP, aggregated at the level of major or minor release, as defined in item#10 of Section 2 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 tab 'C. ASPS Brand List'	Number	Mandatory		Integer value in range 1-16. Will be extended as new Brands join Open Banking
3	Endpoint ID	Reported EndPoint ID as defined in tab tab 'B. Endpoint List' Note: ASPSPs must only report endpoints that have gone live in their systems.	Number	Mandatory		Integer value in range 1-70. 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 have 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 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 have 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 value should be NULL If BCA accounts not supported, then 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).	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 rejected state due to authorisation failing or consent authorisation being rejected b. payment resources in 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 rejected state due to authorisation failing or consent authorisation being rejected d. funds-confirmation-consent resources in rejected state due to authorisation failing or consent authorisation not agreed.	Number	Mandatory		Integer number with value >=0 Conditions 1.Total number of API calls for each endpoint >= API Calls Rejected Status 2.Successful API Calls >= API Calls Rejected Status
10	TPPs Calling APIs (10.9)	This is the number of individual TPPs calling each API end-point. For the avoidance of doubt OBIE is looking to receive the number of discrete TPPs (grouped by TPP ID) and not the number of discrete SSAs onboarded with the ASPSP making the endpoint calls.	Number	Mandatory		Integer number with value >=0
11	API Calls Not Authorised by PSU (10.10)	This is the total number of successful endpoint calls that have not been presented to the PSU for authorisation and the PSU have not authorised. Note: The item refers to the number of endpoint calls which resulted in: a. payments consent resources in AwaitingAuthorisation state that have moved to Rejected state due to PSU not authorising the consent. b. account access consent resources in AwaitingAuthorisation state that have moved to Rejected state due to due to PSU not authorising the consent. c. funds-confirmation-consent resources in AwaitingAuthorisation state that have moved to Rejected state due to due to PSU not authorising the consent. NULL value must be reported for any other endpoint.	Max20AlphaNumericText	Mandatory		Integer number with value >=0 If HTPP method of endpoint is not POST, then 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 endpoint is not a payment consent POST, then 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 2 key usage instructions.	Max40Text	Mandatory		Allowed enumeration values: v1.0, v1.1, v2.0, v3.0, v3.1,...

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 tab 'C. ASPS Brand List'	Number	Mandatory		Integer value in range 1-16. 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 as 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.	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 tab 'C. ASPS Brand List'	Number	Mandatory		Integer value in range 1-16. 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 as 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 tab 'C. ASPS Brand List'	Number	Mandatory		Integer value in range 1-16. Will be extended as new Brands join Open Banking
3	Number of AISPs	This is the number of individual AISPs initiating payments and checking their payment status. 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 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.	Max20AlphaNumericText	Mandatory		Integer number with value >=0

3.8.4 AIS Corporate Account Access

TAB: 3.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 tab 'C. ASPS Brand List'	Number	Optional		Integer value in range 1-16. Will be extended as new Brands join Open Banking
3	Number of AISPs	This is the number of individual AISPs initiating payments and checking their payment status. 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.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 tab 'C. ASPS Brand List'	Number	Mandatory		Integer value in range 1-16. 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 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	Uptime per each individual endpoint 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 2.1.2.	Number	Mandatory		Conditions 1. Core Hours: Uptime + Downtime = 100% 2. Non-Core Hours: Uptime + Downtime = 100%

4. Physical Data Dictionary

4.1 UML Diagram

4.2 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 find here.

4.3 Codelist

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

4.4 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. Version control

Version	Date	Authors	Comments
v1.0-draft1	04 Dec 2018	OBIE API Delivery Team	Initial Draft Version
v1.0-draft2	05 Dec 2018	OBIE API Delivery Team	Draft 2 Changes Removed System Context section from this Data Specification. Updated the definition of fields.
v1.0-draft3	10 Apr 2019	OBIE API Delivery Team	Draft3 Changes: Updated the Reporting Principles section 1, 4 8, 10 and 11. Redesign the API endpoint list table Added Unavailability (Downtime) Definition section Rename OBMIPerformanceOutliersReportData1 class to OBMIResponseOutliersReportData1 Added version field in all classes. Added new classes and fields