# MI Reporting Data API Specification v3.1.2

# 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

 OBIE MI Reporting Data

# 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