# TPP MI Reporting Data API Specifications v3.1.7
# 1. TPP MI Reporting Key Usage Instructions
TPPs should submit MI Data to OBIE according to the definitions provided in the Data Dictionary of the TPP MI Specification.
TPPs must populate the API Endpoint IDs as defined in the section API Endpoint List.
TPPs must populate the TPP Brand IDs as defined in the section TPP Brand List.
TPPs must populate the ASPSP Brand IDs as defined in the section ASPSP Brand List.
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.
The Logical Data Dictionary for each field is defined below in section 3.
Reported MI data in all the reporting data tables must exclude TPP test application data generated during TPPs testing their 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 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.
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 |
| 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 TPP 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:
| Max40Text | Should |
| |
| 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 |
| |
| 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 (4xx codes) | 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 (5xx codes) | 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 | 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 |
Conditions 1. Total Number of API Calls for each endpoint >= API Calls Rejected Status 2. Successful API Calls >= API Calls Rejected Status | |
| 13 | 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 | |
| 14 | 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 | |
| 15 | 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 | |
| 16 | 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 | |
| 17 | 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 | |
| 18 | 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 | Must | [0-6][0-9]:[0-9][0-9] | Minutes and seconds text in the following format: "mm:ss" |
| 19 | Free Format Text | Free format text entries for the opportunity of TPPs raising specific issues or providing comments in free text format for the specific record or data table. | Max40Text | Could | Alphanumeric free format text OR NULL | |
| 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 |
|
# 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 |
| |
| 4 | On behalf of TSP Brand Name | This should be the name of:
| Max40Text | Should |
| |
| 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 |
| |
| 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:
| |
| 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:
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 | Free Format Text | Free format text entries for the opportunity of TPPs raising specific issues or providing comments in free text format for the specific record or data table. | Max40Text | Could |
| |
| 12 | 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 |
| |
| 13 | 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 |
|
# 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 |
| |
| 3 | âOn behalf ofâ / TSP Brand Name | This should be the name of:
| Max40Text | Should |
| |
| 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:
| |
| 6 | API Request TPP Channel | This is the reported TPP channel for initiating the AIS, PIS or CBPII consent. | Max40Text | Should | Allowed enumeration values:
| |
| 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:
| |
| 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 | 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 | |
| 10 | 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 | |
| 11 | Free Format Text | Free format text entries for the opportunity of TPPs raising specific issues or providing comments in free text format for the specific record or data table. | Max40Text | Could |
| |
| 12 | 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:
| |
| 13 | 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 |
|
# 3.1.4 PSU and Consent Adoption
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 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:
| Max40Text | Must |
| |
| 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 |
| |
| 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:
| |
| 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:
For PIS_only API service: | 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 PSUs (i.e. the number of SME business customers that consented to give access to their accounts for each of the API service combinations). For the avoidance of doubt, this is referring to the number of SME businesses which have consented and not the number of users of these businesses that have account access credentials to the businessesâ accounts and have consented. | 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 TPP Brand. | 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. | 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. | 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. Note: This will exclude CBPII/CoF consents as these consents do not expire and need to be revoked. | Number | Must | Integer number with value >=0 | |
| 13 | Long-lived consents - Renewed consents | This is the total number of unique Long-lived consents which have been renewed by PSUs during the reporting period. | Number | Must | Integer number with value >=0 | |
| 14 | 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. | Number | Must | Integer number with value >=0 | |
| 15 | 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). | Number | Must | Integer number with value >=0 Outstanding consents EoP = Outstanding consents BoP - Revoked consents - Expired consents + Renewed consents + New consents | |
| 16 | Free Format Text | Free format text entries for the opportunity of TPPs raising specific issues or providing comments in free text format for the specific record or data table. | Max40Text | Could |
| |
| 17 | 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:
| |
| 18 | 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 |
|
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.
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. (NB: CBPII/CoF consents do not expire and need to be revoked)
- Plus consents renewed.
- Plus new consents.
- Outstanding consents at end of the reporting period (EoP)
# 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.
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.
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.
# 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.
# 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 the initial 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.