icon_search Search
Close X

HOW CAN WE HELP?

# TPP MI Reporting Data API Specifications v3.1.9

# 1. TPP MI Reporting Key Usage Instructions

  1. TPPs should submit MI Data to OBIE according to the definitions provided in the Data Dictionary of the TPP MI Specification.

  2. TPPs must populate the API Endpoint IDs as defined in the section API Endpoint List.

  3. TPPs must populate the TPP Brand IDs as defined in the section TPP Brand List.

  4. TPPs must populate the ASPSP Brand IDs as defined in the section ASPSP Brand List.

  5. TPPs must not submit any empty entries. NULL should always be populated in data fields which are not relevant to an TPP's implementation MI.

  6. The Logical Data Dictionary for each field is defined below in section 3.

  7. Reported MI data in all the reporting data tables must exclude TPP test application data generated during TPPs testing their own implementations.

  8. 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 responded back to the TPPs by the ASPSPs (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 the challenges of measuring "perceived" OBIE API unavailability by TPPs , please refer to section 4.1.

  9. Version Reporting: Where TPPs support more than one major or minor API version in production, each version must be reported separately. For example, v3.0 and v3.1 must be reported separately. However patches, for example, v3.1.1, should be reported as aggregate together with the relevant major or minor release (i.e. together with v3.1). Note: Version reporting will not be mandatory for all the MI Reporting data. Please refer to each table in section 3 of the Data Dictionary for more details in terms of mandatory and optional version reporting.

# 2. Predefined Lists

# 2.1 API Endpoint List

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

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

Note: Using the Endpoint ID and the OBIE Standards version in the reporting tables, provides a unique identifier for each of the reported endpoints of the ASPSPs' implementation.

# 2.2 TPP-TSP Brand List

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

TPP/TSP Brand ID TPP/TSP Brand Name TSP via "On behalf of" or TSP Brand Name
1 Adyen N.V.
2 American Express Payment Services Limited
3 Bank of Cyprus Public Company Ltd
4 Bank of Scotland PLC
5 Barclays Bank UK Plc
6 BOTTOMLINE PAYMENT SERVICES LIMITED
7 BudgetBakers s.r.o.
8 Business Finance Technology Group Limited
9 Cashfac PLC Y
10 Castlight Limited
11 CLEO AI LTD. Y
12 Clydesdale Bank Plc
13 Consents Online Limited
14 Credit Kudos Limited
15 CURRENSEA LIMITED
16 Digital Moneybox Limited
17 Ecospend Technologies Limited
18 Experian Limited
19 FRACTAL LABS LTD
20 FreeAgent Central Limited
21 Funding Options Limited
22 HUBSOLV LTD
23 Indigo Michael Ltd
24 ING Bank N.V.
25 Intuit Limited
26 IWOCA LTD
27 Lloyds Bank PLC
28 Mastercard Europe SA
29 Money Dashboard Ltd
30 Moneyhub Financial Technology Ltd
31 National Westminster Bank Plc
32 Plaid Financial Ltd.
33 PLUM FINTECH LIMITED Y
34 Quick File LTD
35 Reflow Zone Limited
36 Salt Edge Limited
37 Sentenial Limited
38 Skrill Ltd.
39 SPENDEE s.r.o.
40 TANDEM BANK LIMITED
41 The IDCO. LIMITED
42 The Royal Bank of Scotland Plc
43 THE SMART REQUEST COMPANY LTD
44 THIRDFORT LIMITED Y
45 Tink AB
46 Token.io Ltd
47 TransferWise LTD
48 TransUnion International UK Limited
49 TrueLayer Limited
50 Ulster Bank Ltd
51 Xero (UK) Limited
52 Yapily Ltd
53 Y TREE Limited Y
54 Zeux Limited
9999 New TPP

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

# 2.3 ASPSP Brand List

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

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

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

# 3. Logical Data Dictionary

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

The following MoSCoW classification has been used for the requirements:

  • Must - This is essential to be delivered in the TPP MI Reporting
  • Should - This is non-essential but highly desirable to be delivered in the TPP MI Reporting
  • Could - This will be nice to have it delivered in the TPP MI Reporting
  • Would - This presents lower business value compared to the other types of data fields

# 3.1 Generic (Core) MI

The following MI Group is generic (core) and is applicable to all TTP participants irrespective of being AISP, PISP, CBPII or a TSP for licensed TPP participants.

# 3.1.1 Overall Performance

This data set includes measurements of volumes, average response times and perceived availability of the various API endpoints as experienced by TPPs.

Submission Frequency: High

The following data table is required to be submitted to OBIE in a higher than normal frequency. This could be daily or several times during each day. The actual value will be agreed between OBIE and participating TPPs.

TAB: 1A. Overall Performance:

ID Field Name Description/Definition DataType MoSCoW Pattern Format/Values/Comments
1 ReportDate The reported date for each calendar day ISODate Must 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 This is the 1 hour time period for which the reported record relates to. Max40Text Should Allowed enumeration values: (00.00 - 01.00), (01.00 - 02.00), (02.00 - 03.00), (03.00 - 04.00), (04.00 - 05.00), (05.00 - 06.00), (06.00 - 07.00), (07.00 - 08.00), (08.00 - 09.00), (09.00 - 10.00), (10.00 - 11.00), (11.00 - 12.00), (12.00 - 13.00), (13.00 - 14.00), (14.00 - 15.00), (15.00 - 16.00), (16.00 - 17.00), (17.00 - 18.00), (18.00 - 19.00), (19.00 - 20.00), (20.00 - 21.00), (21.00 - 22.00), (22.00 - 23.00), (23.00 - 00.00)
3 TPP Brand ID Reporting or reported TPP Brand ID as defined in section 2.2 TPP/TSP Brand List. This can take the value of NULL if the TPP is connecting via a TSP and the TSP is providing the report but is not willing to identify the TPP. Max40Text Must An integer value in range 1-9999 \ OR NULL
4 “On behalf of” / TSP Brand Name This should be the name of:
  • the TSP Brand Name as defined in section 2.2 TPP/TSP Brand List
  • OR the non-regulated entity commercial name as populated in the Software Statement (this will be in free text format)
  • OR will be populated with NULL value if the TPP connects directly to the ASPSP.
 Max40Text Should
  • An integer value in range 1-9999
  • OR free format text
  • OR NULL
5 ASPSP Brand ID The reported ASPSP Brand ID as defined in section 2.3 ASPSP Brand List, to which the data record relates to. TPPs should split their endpoint traffic according to the ASPSP Brand that they are directed to. Number Must An integer value in range 1-9999. Will be extended as new Brands join Open Banking
6 Retail/Business PSU This identifies whether the TPP endpoint traffic relates to Retail or Business PSUs. TPPs having both retail and Business PSUs must report traffic for both, in separate data records. Max40Text Should
  • Allowed enumeration values:
    • Retail
    • Business
  • OR NULL
7 Endpoint ID The reported EndPoint ID as defined in section 2.1 API Endpoint List. Number Must An integer value in range 1-9999. Will be extended as new endpoints are being implemented by Open Banking future standards.
8 Total Number of API Calls This is the total number of endpoint calls for each endpoint that have been made by the TPP/TSP to the reported ASPSP during the reported 1 hour period. Number Must 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) + Timed Out API Calls
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)
5. Total Number of API Calls for each endpoint >= Timed Out API Calls
9 Successful API Calls
(200, 201 or 204 codes)		 This is the total number of successful endpoint calls for each endpoint that have been made by the TPP/TSP to the reported ASPSP during the reported 1 hour period and generated a response message back to the TPP/TSP with an HTPP Status Code of 200, 201 or 204 depending on the HTTP method of the endpoints. Number Must Integer number with value >=0
10 Failed API Calls Business Reasons
This is the total number of failed endpoint calls for each endpoint that have been made by the TPP/TSP to the reported ASPSP during the reported 1 hour period and generated a failure response message back to the TPP/TSP due to business rules reasons (response with HTPP Status Code of 4xx). Number Must Integer number with value >=0
11 Failed API Calls Technical Reasons
 This is the total number of failed endpoint calls for each endpoint that have been made by the TPP/TSP to the reported ASPSP during the reported 1 hour period and generated a failure response message back to the TPP/TSP due to technical reasons (response with an HTPP Status Code of 500 Internal Server Error).
Note: TPPs should exclude the impact of 5xx calls or Timed Out API calls during a period of Planned Outage. For the avoidance of doubt, this means that these endpoint calls will not be reported.		 Number Must Integer number with value >=0
12 Failed API Calls -No response
 This is the total number of failed endpoint calls for each endpoint that has been made by the TPP/TSP to the reported ASPSP during the reported 1 hour period and generated no response message back to the TPP/TSP.
Note: TPPs should exclude the impact of no response calls during a period of Planned Outage. For the avoidance of doubt, this means that these endpoint calls will not be reported.		 Number Must Integer number with value >=0
13 API Calls generating Rejection Status This is the total number of endpoint calls that have generated rejection status for each endpoint.
Note:
The item refers to the number of endpoint calls which resulted in:
a. payments consent resources in the rejected state due to authorisation failing or consent authorisation being rejected
b. payment resources in the rejected state due to payment initiation being rejected as part of proceeding checks such as technical validation and customer profile
c. account access consent resources in the rejected state due to authorisation failing or consent authorisation being rejected
d. funds-confirmation-consent resources in the rejected state due to authorisation failing or consent authorisation not agreed.		 Max40Text Should
  • Integer number with value >=0
  • OR NULL

Conditions
1. Total Number of API Calls for each endpoint >= API Calls Rejected Status
2. Successful API Calls >= API Calls Rejected Status
14 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 reported 1 hour period for each reported ASPSP.
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 (excluding any Timed Out API Calls)		 Number Must Integer number with value >=0
15 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 reported 1 hour period for each reported ASPSP.
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 (excluding any Timed Out API Calls).		 Max40Text Should Integer number with value >=0
OR NULL
16 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 reported 1 hour period for each reported ASPSP.
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 (excluding any Timed Out API Calls).		 Max40Text Could Integer number with value >=0
OR NULL
17 Minimum TTLB API response time -(Best case) This is the minimum TTLB response time in ms from all the API calls of the endpoint type during the reported period of 1 hour. This is the best case of API response time. Max40Text Should Integer number with value >=0
OR NULL
18 Maximum TTLB API response time -(Worse case) This is the maximum TTLB response time in ms from all the API calls of the endpoint type during the reported period of 1 hour. This is the worse best case of API response time. Max40Text Should Integer number with value >=0
OR NULL
19 Perceived API Unavailability Any unplanned duration that the API endpoints are 'perceived' to have 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. The clock for unavailability should start as defined in section 4.1, should include any Timed Out API Calls and calls with responses of 5xx, and consolidated duration must be reported during the 1 hour reported period, as elapsed time.
(Please refer to section 4.1 about challenges of measuring Perceived API Unavailability).		 Max5Text Mandatory [0-6][0-9]:[0-9][0-9] Minutes and seconds text in the following format: "mm:ss"
20 Version The OBIE Standards version of the endpoint implementation by the TPP, aggregated at the level of a major or minor release, as defined in item#9 of Section 1 TPP MI Reporting Key Usage Instructions. Max40Text Should Allowed enumeration values:
v1.0, v1.1, v2.0, v3.0, v3.1,...
OR NULL
21 CEF Outcome Area In alignment to the Consumer Evaluation Framework and especially in relation to the defined outcome area and the directly related propositions, TPPs are expected to label the submitted data records with the defined outcome area of their proposition. If TPPs have multiple propositions that fall within various outcome areas, they are expected to report each data set relating to each outcome area separately. Max40Text Should
  • Allowed enumeration values:
    • Improved_financial_decision_making
    • Increased_access_to advice_and_guidance
    • Better_borrowing
    • Increased_saving_and_investing
    • Expanded_payments_choice
    • Increased_switching
  • OR NULL

# 3.1.2 End-to-End Response Times

This data set includes measurements of the end-to-end service timings as experienced by TPPs and their PSUs for the various API services.

Submission Frequency: Normal

The following data table is required to be submitted to OBIE at normal frequency. This is currently considered to be on a monthly basis. The actual value will be agreed between OBIE and participating TPPs.

TAB: 1B. End-to-End Response Times

ID Field Name Description/Definition DataType MoSCoW Pattern Format/Values/Comments
1 ReportDate The reported date for each calendar day ISODate Must 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 This is the 1 hour time period for which the reported record relates to. Max40Text Should * Allowed enumeration values: \ (00.00 - 01.00), (01.00 - 02.00), (02.00 - 03.00), (03.00 - 04.00), (04.00 - 05.00), (05.00 - 06.00), (06.00 - 07.00), (07.00 - 08.00), (08.00 - 09.00), (09.00 - 10.00), (10.00 - 11.00), (11.00 - 12.00), (12.00 - 13.00), (13.00 - 14.00), (14.00 - 15.00), (15.00 - 16.00), (16.00 - 17.00), (17.00 - 18.00), (18.00 - 19.00), (19.00 - 20.00), (20.00 - 21.00), (21.00 - 22.00), (22.00 - 23.00), (23.00 - 00.00) \ * OR NULL
3 TPP Brand ID Reporting or reported TPP Brand ID as defined in section 2.2 TPP/TSP Brand List. This can take the value of NULL if the TPP is connecting via a TSP and the TSP is providing the report but is not willing to identify the TPP. Max40Text Must
  • An integer value in range 1-9999
  • OR NULL
4 On behalf of TSP Brand Name This should be the name of:
  • the TSP Brand Name as defined in section 2.2 TPP/TSP Brand List
  • OR the non-regulated entity commercial name as populated in the Software Statement (this will be in free text format)
  • OR will be populated with NULL value if the TPP connects directly to the ASPSP.
 Max40Text Should
  • An integer value in range 1-9999
  • OR free format text
  • OR NULL
5 ASPSP Brand ID The reported ASPSP Brand ID as defined in section 2.3 ASPSP Brand List, to which the data record relates to. TPPs should split their endpoint traffic according to the ASPSP Brand that they are directed to. Number Must An integer value in range 1-9999. Will be extended as new Brands join Open Banking
6 Retail/Business PSU This identifies whether the TPP endpoint traffic relates to Retail or Business PSUs. TPPs having both retail and Business PSUs must report traffic for both, in separate data records. Max40Text Should
  • Allowed enumeration values:
    • Retail
    • Business
  • OR NULL
7 API Service This identifies the API service the reported end-to-end Total TTLB Response Time for each ASPSP during the reported 1 hour period relates to, including Account Information (AIS), Payment Initiation (PIS) and Card-Based Payment Instrument Issuers (CBPII). Each service must be reported separately, if many are offered by the same TPP/TSP. Max40Text Must Allowed enumeration values:
  • AIS
  • PIS
  • CBPII
8 Total Number of Requests This is the total number of service requests, either for payment initiation, account information or Confirmation of Funds that have been made by the TPP/TSP to the reported ASPSP during the reported 1 hour period. Number Must Integer number with value >= 0
9 Time Period Depending on how TPPs want to report for end-to-end timings, this can either be:
  • Ttot (for the sume of T1 + T2 + T4 + T6 time segements) and T3 (optional) and T5 seperate OR
  • each time segment T1, T2, T3, T4, T5, T6 can be reported separately and allow OBIE to consolidate the resulting total end-to-end time. In this case there would be a record for every time segment entry (apart from the optional T3 and T5)

Please note that the above timing segments include the TPP’s internal overhead and processing time taken during the end-to-end journey. This would be different from the reporting endpoint response times which they solely focus on the time period from sending the API endpoint call till receiving all the information included in the API endpoint response.
(Please refer to section 4.2 Measuring End-to-End Response times)
 Max40Text Must Allowed enumeration values: \ T1, T2, T3, T4, T5, T6. and Ttot
10 Total Time Period Duration This is the sum of all the Time Period Duration of all service requests during the reported 1 hour period for each reported ASPSP. For the avoidance of doubt, this is the sum of all the Time Period Duration generated by the Total Number of of Requests for each API Service request during the related Time Period segment. Number Must Integer number with value >=0
11 Version The OBIE Standards version of the endpoint implementation by the TPP, aggregated at the level of a major or minor release, as defined in item#9 of Section 1 TPP MI Reporting Key Usage Instructions. Max40Text Should
  • Allowed enumeration values:
  • v1.0, v1.1, v2.0, v3.0, v3.1
  • OR NULL
12 CEF Outcome Area In alignment to the Consumer Evaluation Framework and especially in relation to the defined outcome area and the directly related propositions, TPPs are expected to label the submitted data records with the defined outcome area of their proposition. If TPPs have multiple propositions that fall within various outcome areas, they are expected to report each data set relating to each outcome area separately. Max40Text Should
  • Allowed enumeration values:
    • Improved_financial_decision_making
    • Increased_access_to advice_and_guidance
    • Better_borrowing
    • Increased_saving_and_investing
    • Expanded_payments_choice
    • Increased_switching
  • OR NULL

# 3.1.3 Auth Efficacy

This data set includes measurements similar to those reported by ASPSPs, including authentication success and failures per initiating channel (web or mobile), additional user interaction failures etc. In general, this is one of the sources for measuring the user drop-out rates per TPP and per ASPSP.

Submission Frequency: Normal

The following data table is required to be submitted to OBIE at normal frequency. This is currently considered to be on a monthly basis. The actual value will be agreed between OBIE and participating TPPs.

TAB: 2. Auth Efficacy

ID Field Name Description/Definition DataType MoSCoW Pattern Format/Values/Comments
1 ReportMonth Reported calendar month and year Max6Text Must ^(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)-\d{2}$ (mmm-yy)
2 TPP Brand ID Reporting or reported TPP Brand ID as defined in section 2.2 TPP/TSP Brand List. This can take the value of NULL if the TPP is connecting via a TSP and the TSP is providing the report but is not willing to identify the TPP. Max40Text Must
  • An integer value in range 1-9999
  • OR NULL
3 “On behalf of” / TSP Brand Name This should be the name of:
  • the TSP Brand Name as defined in section 2.2 TPP/TSP Brand List
  • OR the non-regulated entity commercial name as populated in the Software Statement (this will be in free text format)
  • OR will be populated with NULL value if the TPP
 Max40Text Should
  • An integer value in range 1-9999
  • OR free format text
  • OR NULL
4 ASPSP Brand ID The reported ASPSP Brand ID as defined in section 2.3 ASPSP Brand List, to which the data record relates to. TPPs should split their endpoint traffic according to the ASPSP Brand that they are directed to. Number Must An integer value in range 1-9999. Will be extended as new Brands join Open Banking
5 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 Must Allowed enumeration values:
  • AIS
  • PIS
  • CBPII
6 API Request TPP Channel This is the reported TPP channel for initiating the AIS, PIS or CBPII consent. Max40Text Should Allowed enumeration values:
  • Browser
  • Non-Browser
  • Other
7 ASPSP Authentication Channel This is the reported ASPSP Authentication channel. It can be web-based (Web) or using the mobile banking app (App). In some cases this may be unknown. Max40Text Should Allowed enumeration values:
  • Web
  • App
  • Unknown
8 Consents requiring Authentication The total number of PSU consents to require authentication at the ASPSP for the particular combination of API type, TPP channel and ASPSP authentication channel. Number Must Integer number with value >=0
9 Consents abandoned by PSU before redirection The total number of PSU consents to require authentication that has been abandoned by the PSUs before redirection. This means that PSUs have dropped the journey (they have left, closed the web page or app or timed out before redirection). Number Must Integer number with value >=0
10 Consents abandoned by TPP before redirection The total number of PSU consents to require authentication that has been abandoned by the TPP where there was no redirection.
E.g. Polling		 Number Must Integer number with value >=0
11 Authentications Succeeded The total number of consents requiring authentication that have completed authentications by PSUs and the authentications have succeeded Number Must Integer number with value >=0
12 Authentications Failed The total number of consents requiring authentication that have completed authentications by PSUs and the authentications have failed or rejected by PSUs. Number Must Integer number with value >=0
13 Average journey time The total average time it took to complete a journey for each API type in the reporting period.
Total average time=Ttot (for the sum of T1 + T2 + T3 + T4 + T5 + T6 time segments)
Refer to MI Requirements for TPPs v3.1.9 Section 8.2-Measuring-End-to-End-Response-times for Ttot example		 Number Must
14 Version The OBIE Standards version of the endpoint implementation by the TPP, aggregated at the level of a major or minor release, as defined in item#9 of Section 1 TPP MI Reporting Key Usage Instructions. Max40Text Should Allowed enumeration values:
  • v1.0, v1.1, v2.0, v3.0, v3.1
  • OR NULL
15 CEF Outcome Area In alignment to the Consumer Evaluation Framework and especially in relation to the defined outcome area and the directly related propositions, TPPs are expected to label the submitted data records with the defined outcome area of their proposition. If TPPs have multiple propositions that fall within various outcome areas, they are expected to report each data set relating to each outcome area separately. Max40Text Should
  • Allowed enumeration values:
    • Improved_financial_decision_making
    • Increased_access_to advice_and_guidance
    • Better_borrowing
    • Increased_saving_and_investing
    • Expanded_payments_choice
    • Increased_switching
  • OR NULL

Example Flow Diagram : To illustrate how Auth Efficacy data is populated and related to consent status. The key areas where PSU drop-offs can be measured in the TPP space.

Consent success rate calculation logic: Total consents that have been successfully authorised by PSU (those that ended in consent status= Authorised ) / Total consents that were attempted by the PSU to authenticate

Example1:PIS_Consent_Success_rate_calculation_for_redirection_authentication_type

# 3.1.4 PSU and Consent Adoption per ASPSP brand

This data set includes measurements similar to the ones recently introduced to the MI for ASPSPs, further to the proposal from the OFT. It includes a new and cumulative number of PSUs per service split by Retail and SME and also the number of consents (long and short term) to measure the intensity of the service adoption.

Submission Frequency: Normal

The following data table is required to be submitted to OBIE at normal frequency. This is currently considered to be on a monthly (or sooner e.g. weekly) basis. The actual value will be agreed between OBIE and participating TPPs.

TAB: 3. PSU and Consent Adoption

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportMonth Reported calendar month and year Max6Text Must ^(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)-\d{2}$ (mmm-yy)
2 TPP Brand ID Reporting or reported TPP Brand ID as defined in section 2.2 TPP Brand List. This can take the value of NULL if the TPP is connecting via a TSP and the TSP is providing the report but is not willing to identify the TPP. Number Must An integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 On behalf of / TSP Brand Name This should be the name of:
  • the TSP Brand Name as defined in section 2.2 TPP/TSP Brand List
  • OR the non-regulated entity commercial name as populated in the Software Statement (this will be in free text format)
  • OR will be populated with a NULL value if the TPP connects directly to the ASPSP.
 Max40Text Must
  • An integer value in range 1-9999
  • OR free format text
  • OR NULL
4 ASPSP Brand ID Reported ASPSP Brand ID as defined in section 2.3 ASPSP Brand List. Number Must An integer value in range 1-9999. Will be extended as new Brands join Open Banking
5 Retail/Business PSUs This identifies Retail and Business PSUs for separate reporting. Max40Text Should
  • Allowed enumeration values:
    • Retail
    • Business
  • OR NULL
6 API Service This identifies the API service the PSU is using, including Account Information (AIS), Payment Initiation (PIS) and Card-Based Payment Instrument Issuers (CBPII). Each service must be reported separately and also all the possible combinations of services a PSU maybe using offered by the TPP.
The PSUs reported for each type of API service combination are distinct users in order to avoid double counting.		 Max40Text Must Allowed enumeration values:
  • AIS_only
  • PIS_only
  • CBPII_only
  • AIS_&_PIS
  • AIS_&_CBPII
  • PIS_&_CBPII
  • AIS_&_PIS_&_CBPII
7 Active PSUs This is the total number of TPP-level PSUs (i.e. the number of customers that give access to accounts for each of the API service combinations).
For the avoidance of doubt, this includes all customers (consumers and account holders of SME businesses) who;
For AIS_only API service:
  1. Have an active long-lived AIS consent at the end of the reporting period OR
  2. Have provided a one-off AIS consent during the current reporting period OR
  3. Have both an active AIS consent at the end of the reporting period AND have provided a one-off AIS consent during the current reporting period (These must be counted as one PSU).

    4. For PIS_only API service:
  4. Have provided a one-off PIS consent during the current reporting period (payment initiation instruction).
    5. For CBPII_only service:
  5. Have an active CBPII/CoF consent at the end of the reporting period.
    6. For AIS_&_PIS service:
  6. Have performed a combination of rules 1. to 3. AND rule 4. (These must be counted as one PSU)
    7. For AIS_&_CBPII service:
  7. Have performed a combination of rules 1. to 3. AND rule 5. (These must be counted as one PSU)
    8. For PIS_&_CBPII service:
  8. Have performed a combination of rule 4. AND 5. (These must be counted as one PSU)
    9. For AIS_PIS_&_CBPII service:
  9. Have performed a combination of rules 1. to 3. AND rule 4. AND rule 5 (These must be counted as one PSU)

Note: PSU is considered active if they have at least one active long-lived consent at the time of reporting. The PSU should be counted only once under any of the above-mentioned API Service.
E.g 1: PSU has given consent for 'x' months to the TPP for AIS services and has initiated a payment with the same TPP using PIS services in the reporting month then the PSU should be counted once under AIS_&_PIS.
E.g. 2: PSU should not be counted if the PSU has given consent for 'x' months to TPP for AIS services in a reporting month however the PSU has also revoked the same consent at the TPP in the same reporting month.		 Number Must Integer number with value >=0
AIS_only Active PSUs +
PIS_only Active PSUs +
CBPII_only Active PSUs +
AIS_&_PIS Active PSUs +
AIS_&_CBPII Active PSUs +
PIS_&_CBPII Active PSUs +
AIS_&_PIS_&_CBPII Active PSUs =
Total Active PSUs within ASPSP (unique)
8 Active SME Businesses This is the total number of TPP-level SME Business (i.e. the number of SME business customers that consented to give access to their accounts for each of the API service combinations)
For the avoidance of doubt, this is referring to the number of SME businesses which have consented and not the number of users of these businesses that have account access credentials to the businesses' accounts and have consented.		 Max20AlphaNumericTex Must Integer number with value >=0
If Retail/Business PSUs is ‘Retail’: NULL
For Business PSUs, if Active PSUs >0 then Active SME Businesses >0
For Business PSUs, if Active SME Businesses >0, then Active PSUs >0
9 One-off Consents This is the total unique One-off consents for AIS or PIS API services for each Consumer or Business PSU type of each ASPSP Brand.
For the avoidance of doubt this refers to:
- all payment consent resource types (including domestic-payment-consents, domestic-scheduled-payment-consents, domestic-standing-order-consents, international-payment-consents, international-scheduled-payment-consents, international-standing-order-consents and file-payment-consents) and
- account-access-consent resources with an expiry date of less or equal to 15 days duration from the day they have been authorised		 Number Must Integer number with value >=0
10 Long-lived consents - Outstanding consents BoP This is the total number of unique Long-lived consents which are Outstanding at the beginning of the reporting period (BoP).
For the avoidance of doubt, outstanding consents refers:
- to all consents which are active at the beginning of the reporting period.
- account-access-consent resources in ‘Authorised’ state with an expiry date, if specified, of more than 15 days duration from the day they have been authorised		 Number Must Integer number with value >=0
11 Long-lived consents - Revoked consents This is the total number of unique Long-lived consents which have been revoked by PSUs during the reporting period.
For the avoidance of doubt this refers to account-access-consent resources:
- with an expiry date, if specified, of more than 15 days duration from the day they have been authorised.
- that have been set to ‘revoked’ state during the reporting period		 Number Must Integer number with value >=0
12 Long-lived consents - Expired consents This is the total number of unique Long-lived consents which have expired during the reporting period.
For the avoidance of doubt this refers to account-access-consent resources:
- with an expiry date of more than 15 days duration from the day they have been authorised
- that the expiration Date Time has elapsed sometime during the reporting period and all access permissions previously consented have now been stopped.		 Number Must Integer number with value >=0
13 Long-lived consents - Consents Requiring Reauthentication This is the total number of unique Long-lived consents which required 90 days PSU re-authentication, as per the RTS requirements.
For the avoidance of doubt this refers to account-access-consent resources:- with an expiry date, if specified, of more than 15 days duration from the day they have been authorised, or no expiry date defined
- that have resource status of ‘Authorised’
- that the expiry date, if specified, has not elapsed
- the PSU has not re-authenticated the account-access consent for 90 days.
 Number Mandatory Integer number with value >=0
14 Long-lived consents - Refreshed consents This is the total number of unique Long-lived consents which have been refreshed (i.e. reauthenticated)by PSUs during the reporting period.
For the avoidance of doubt this refers to account-access-consent resources:
- with an expiry date, if specified, of more than 15 days duration from the day they have been authorised
- that have resource status of ‘Authorised’
- that the expiry data, if specified, has not elapsed
- that required PSU re-authentication due to the 90 days RTS requirement (as defined in item #9, Long-lived consents - Consents Requiring Reauthentication)
- the PSU has re-authenticated the account-access consent during the reporting period
Note: If the PSU re-authenticates the account-access consent, before the 90 days period, (i.e. the consent is not counted in item #9, Long-lived consents - Consents Requiring Reauthentication), then the PSU re-authentication should not be counted in this metric as well.		 Number Must Integer number with value >=0
15 Long-lived consents - New consents This is the total number of unique new Long-lived consents which have been consented to by PSUs during the reporting period.
For the avoidance of doubt, new consents refer to account-access-consent resources:
- with an expiry date, if specified, of more than 15 days duration from the day they have been authorised
- that have resource status of ‘Authorised’		 Number Must Integer number with value >=0
16 Long-lived consents - Outstanding consents EoP This is the total number of unique Long-lived consents which are Outstanding at the end of the reporting period (EoP).
For the avoidance of doubt, outstanding consents refer to:
- all consents which are active at the end of the reporting period
- account-access-consent resources in ‘Authorised’ state with an expiry date, if specified, of more than 15 days duration from the day they have been authorised		 Number Must Integer number with value >=0
Outstanding consents EoP = Outstanding consents BoP - Revoked consents - Expired consents - Consents Requiring Reauthentication + Refreshed consents + New consents
17 Long-lived consents - Total Refreshed consents This is the total number of unique Long-lived consents which have been refreshed (i.e. reauthenticated) by PSUs during the reporting period. Number Must Integer number with value >=0
18 PSUs used OB API Services for the first time The number of unique PSUs who have given consent for API service (#6) for the first time during the reporting period.
For the avoidance of doubt, this refers to new consent/authorisations and not re-authorisations.
For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately.		 Number Must Integer number with value >=0
19 Total PSUs used OB API Services The total number of unique PSUs who have given consent for the first time or have previously given consent and have accessed the service during the reporting period for the API service (#6) Number Must Integer number with value >=0
Conditions
Total PSUs used OB API Services >= PSUs used OB API Services for the first time
20 Version The OBIE Standards version of the endpoint implementation by the TPP, aggregated at the level of a major or minor release, as defined in item#9 of Section 1 TPP MI Reporting Key Usage Instructions. Max40Text Should Allowed enumeration values:
  • v1.0, v1.1, v2.0, v3.0, v3.1,…
  • OR NULL
21 CEF Outcome Area In alignment to the Consumer Evaluation Framework and especially in relation to the defined outcome area and the directly related propositions, TPPs are expected to label the submitted data records with the defined outcome area of their proposition. If TPPs have multiple propositions that fall within various outcome areas, they are expected to report each data set relating to each outcome area separately. Max40Text Should
  • Allowed enumeration values:
    • Improved_financial_decision_making
    • Increased_access_to advice_and_guidance
    • Better_borrowing
    • Increased_saving_and_investing
    • Expanded_payments_choice
    • Increased_switching
  • OR NULL

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

A. Flow only data requirements:

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

B. Stock and Flow only data requirements:

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

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

# 3.1.5 PSU and Consent Adoption

This data set includes measurements similar to the one in section 3.1.4, however, this is to measure consolidated PSU adoption by TPP service, further to the proposal from the OFT. It includes a new and cumulative number of PSUs using the service and for the first time to measure the intensity of the service adoption and enable comparison with ASPSP MI.

Submission Frequency: Normal

The following data table is required to be submitted to OBIE at normal frequency. This is currently considered to be on a monthly (or sooner e.g. weekly) basis. The actual value will be agreed between OBIE and participating TPPs.

TAB: 4A. PSU and Consent Adoption

ID Field Name Description/Definition DataType Occurrence Pattern Format/Values/Comments
1 ReportMonth Reported calendar month and year Max6Text Must ^(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)-\d{2}$ (mmm-yy)
2 TPP Brand ID Reporting or reported TPP Brand ID as defined in section 2.2 TPP Brand List. This can take the value of NULL if the TPP is connecting via a TSP and the TSP is providing the report but is not willing to identify the TPP. Number Must An integer value in range 1-9999. Will be extended as new Brands join Open Banking
3 On behalf of / TSP Brand Name This should be the name of:
  • the TSP Brand Name as defined in section 2.2 TPP/TSP Brand List
  • OR the non-regulated entity commercial name as populated in the Software Statement (this will be in free text format)
  • OR will be populated with a NULL value if the TPP connects directly to the ASPSP.
 Max40Text Must
  • An integer value in range 1-9999
  • OR free format text
  • OR NULL
4 Retail/Business PSUs This identifies Retail and Business PSUs for separate reporting. Max40Text Should
  • Allowed enumeration values:
    • Retail
    • Business
  • OR NULL
5 API Service This identifies the API service the PSU is using, including Account Information (AIS), Payment Initiation (PIS) and Card-Based Payment Instrument Issuers (CBPII). Each service must be reported separately and also all the possible combinations of services a PSU maybe using offered by the TPP.
The PSUs reported for each type of API service combination are distinct users in order to avoid double counting.		 Max40Text Must Allowed enumeration values:
  • AIS_only
  • PIS_only
  • CBPII_only
  • AIS_&_PIS
  • AIS_&_CBPII
  • PIS_&_CBPII
  • AIS_&_PIS_&_CBPII
6 Active PSUs This is the total number of TPP-level PSUs (i.e. the number of customers that give access to accounts for each of the API service combinations).
For the avoidance of doubt, this includes all customers (consumers and account holders of SME businesses) who;
For AIS_only API service:
  1. Have an active long-lived AIS consent at the end of the reporting period OR
  2. Have provided a one-off AIS consent during the current reporting period OR
  3. Have both an active AIS consent at the end of the reporting period AND have provided a one-off AIS consent during the current reporting period (These must be counted as one PSU).

    4. For PIS_only API service:
  4. Have provided a one-off PIS consent during the current reporting period (payment initiation instruction).
    5. For CBPII_only service:
  5. Have an active CBPII/CoF consent at the end of the reporting period.
    6. For AIS_&_PIS service:
  6. Have performed a combination of rules 1. to 3. AND rule 4. (These must be counted as one PSU)
    7. For AIS_&_CBPII service:
  7. Have performed a combination of rules 1. to 3. AND rule 5. (These must be counted as one PSU)
    8. For PIS_&_CBPII service:
  8. Have performed a combination of rule 4. AND 5. (These must be counted as one PSU)
    9. For AIS_PIS_&_CBPII service:
  9. Have performed a combination of rules 1. to 3. AND rule 4. AND rule 5 (These must be counted as one PSU)

Note: PSU is considered active if they have at least one active long-lived consent at the time of reporting. The PSU should be counted only once under any of the above-mentioned API Service.
E.g 1: PSU has given consent for 'x' months to the TPP for AIS services and has initiated a payment with the same TPP using PIS services in the reporting month then the PSU should be counted once under AIS_&_PIS.
E.g. 2: PSU should not be counted if the PSU has given consent for 'x' months to TPP for AIS services in a reporting month however the PSU has also revoked the same consent at the TPP in the same reporting month.		 Number Must Integer number with value >=0
AIS_only Active PSUs +
PIS_only Active PSUs +
CBPII_only Active PSUs +
AIS_&_PIS Active PSUs +
AIS_&_CBPII Active PSUs +
PIS_&_CBPII Active PSUs +
AIS_&_PIS_&_CBPII Active PSUs =
Total Active PSUs within ASPSP (unique)
7 Active SME Businesses This is the total number of TPP-level SME Business (i.e. the number of SME business that consented to give access to their accounts for each of the API service combinations)
For the avoidance of doubt, this is referring to the number of SME businesses which have consented and not the number of users of these businesses that have account access credentials to the businesses' accounts and have consented.		 Max20AlphaNumericTex Must Integer number with value >=0
If Retail/Business PSUs is ‘Retail’: NULL
For Business PSUs, if Active PSUs >0 then Active SME Businesses >0
For Business PSUs, if Active SME Businesses >0, then Active PSUs >0
8 PSUs used OB API Services for the first time The number of unique PSUs who have given consent for API service (#5) for the first time during the reporting period.
For the avoidance of doubt, this refers to new consent/authorisations and not re-authorisations.
For business customers, unique PSUs should refer to all employees of the business who have separate authentication credentials and can be identified separately.		 Number Must Integer number with value >=0
9 Total PSUs used OB API Services The total number of unique PSUs who have given consent for the first time or have previously given consent and have accessed the service during the reporting period for the API service (#5) Number Must Integer number with value >=0
Conditions
Total PSUs used OB API Services >= PSUs used OB API Services for the first time
10 Version The OBIE Standards version of the endpoint implementation by the TPP, aggregated at the level of a major or minor release, as defined in item#9 of Section 1 TPP MI Reporting Key Usage Instructions. Max40Text Should Allowed enumeration values:
  • v1.0, v1.1, v2.0, v3.0, v3.1,…
  • OR NULL
11 CEF Outcome Area In alignment to the Consumer Evaluation Framework and especially in relation to the defined outcome area and the directly related propositions, TPPs are expected to label the submitted data records with the defined outcome area of their proposition. If TPPs have multiple propositions that fall within various outcome areas, they are expected to report each data set relating to each outcome area separately. Max40Text Should
  • Allowed enumeration values:
    • Improved_financial_decision_making
    • Increased_access_to advice_and_guidance
    • Better_borrowing
    • Increased_saving_and_investing
    • Expanded_payments_choice
    • Increased_switching
  • OR NULL

# 4 Additional Information

# 4.1 Challenges of measuring "perceived" OBIE API unavailability by TPPs

Measuring perceived availability of the OBIE API Services offered by the ASPSPs, has several challenges and can only be achieved under very specific circumstances are explained below.

The challenge for TPPs measuring API service availability is originated from the fact that TPPs have no real visibility of when the actual service is in downtime or in uptime. TPPs can only report the experience they perceive from the outcome of an endpoint call. Thus, if an endpoint is not responded within a certain period of time (e.g. 15 sec) then a TPP will timeout on waiting for its response. The TPP may retry this a few more times and again timeout on waiting for the response, however this activity will not continue indefinitely and the TPP will finally abort trying to send the endpoint message. The TPP at a later point in time will try to make another endpoint call, and this may be successful and receive a response. However, the ASPSP service may have become available much earlier than the point in time the TPP will attempt to make another endpoint call, and thus, if the TPP has marked the perceived unavailability as the time period between the previously failed endpoint call until the next successful endpoint, then accuracy of the perceived availability will heavily depend of the frequency of making the endpoint calls.

For example, if a TPP is making a group of endpoint calls twice a day (morning & evening with 12 hours interval) and the morning endpoint calls fail, while the afternoon calls are successful, the TPP will be reporting a "perceived unavailability" of 12 hours, while the true unavailability may have been only a few minutes in the morning during first group of endpoint calls. This is illustrated in the diagram below, where the assumption is that the TPP will start its perceived unavailability after 2 failed endpoints calls, and will stop this at the point of the first successful endpoint call, 12 hours later.

TTFB

Similar issue exists if the TPP marks as a perceived unavailability only the cases where the endpoints fail during the reporting window. In the example shown below, the TPP times out within 15 seconds for each of the 2 endpoint calls and then stops trying to make any more calls until 12 hours later. In this case, the TPPs perceived availability would be 30 seconds, while the true unavailability of the ASPSP would be much longer, e.g. 2 hours.

TTFB

As stated earlier, the accuracy of the "perceived unavailability" would heavily depend on the spreading of the endpoint calls during the reporting window. However, if OBIE collects "perceived unavailability" data from multiple TPPs, we may be able to have enough data entries to profile the unavailability with enough characteristic information, especially for the PIS and CBPII services which are depending on the PSU payments usage patterns during the day and do not present the "batch" behaviours experienced by AISPs. This issue will be discussed with TPPs during early consultation and assess the feasibility of this approach.

Moreover, OBIE is looking to request TPPs to provide redacted data sets of logging information from their own monitoring of the service availability especially during reporting periods where higher than normal error rates (time outs or 5xx errors) take place.

Both the above points are illustrated in the diagram below. If OBIE collects several data from multiple TPPs spread across the reporting period, then OBIE may have enough perceived unavailability periods to reflect the real unavailability period sufficiently. Moreover, if OBIE collects data logs from TPPs with endpoint failures with timestamps, OBIE may be able to also calculate perceived unavailability including any gaps between the TPPs' endpoint calls and reflect unavailability with even more accuracy.

TTFB

# 4.2 Measuring End-to-End Response times

Using OBIE Standards, a service request from a TPP, for example, a payment initiation requested by a PISP, requires a number of API endpoint calls in order to be completed. While reporting at the endpoint level has undoubted business value, OBIE would also like to receive measurements of the end-to-end journeys for PIS, AIS and CBPII as they will be experienced by the TPPs end users. The diagram below shows the various steps and the endpoint calls for initiating a payment, which is in the most complex case between AIS, PIS and CBPII.

In the web sequence diagram below, we have split the total end-to-end time Ttot into a number of different time period steps, namely T1, T2, T3, T4, T5, and T6. This is to provide granularity but also flexibility for a reporting TPP to have the option to include or exclude the PSU interaction time from the total end-to-end journey or the case where CoF was requested as part of the journey. Thus:

  • Ttot = T1 + T2 + T4 + T6 , (excluding the time of PSU interaction with the ASPSP for authenticating and other actions such as selecting a debit account, supplementary information etc) and no CoF
  • Ttot = T1 + T2 + T3 + T4 + T6 , (including the time of PSU interaction with the ASPSP for authenticating and other actions such as selecting a debit account, supplementary information etc) and no CoF
  • *tot = T1 + T2 + T3 + T4 + T5+ T6 , (including the time of PSU interaction with the ASPSP for authenticating and other actions such as selecting a debit account, supplementary information etc) and performing CoF

TPPs may be able to report either Ttot = T1 + T2 + T4 + T6 and report T3 and T5 separately, or report on each time segment separately and allow OBIE to consolidate the resulting total end-to-end time. This will be discussed and agreed with TPPs.

Please note that the above timing segments include the TPP's internal overhead and processing time taken during the end-to-end journey. This would be different from the reporting endpoint response times which they solely focus on the time period from sending the API endpoint call till receiving all the information included in the API endpoint response.

TTFB

# 5. Example Reporting Template

An example of reporting that may be used for the reporting of the data elements described in this Data Dictionary will not be provided with this version of the TPP MI Specification. An example reporting template, may be provided by OBIE upon request.

# 6. MI Data JSON Schema

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

# 7. Version control

Version Date Authors Comments
V0.1 13 Aug 2021 API Delivery Team Initial draft for Industry consultatoin
V0.2 29 Sep 2021 API Delivery Team Submitted to IESG & Approved