A2(c)(ii) Requirements for Enhanced MI Data Submission Mechanism and TPP MI Reporting Data - Change Log RC1

Detailed list of changes between A2(c)(ii) Requirements for Enhanced MI Data Submission Mechanism and TPP MI Reporting Data - DRAFT-1 and A2(c)(ii) Requirements for Enhanced MI Data Submission Mechanism and TPP MI Reporting Data, based on feedback received between  and 

Changes are indicated as follows. Copy which has been removed is struck out and copy which has been added is in blue.

IDSectionChangeReason for Change
11. Purpose

The purpose of this document is to provide a consolidated view of the requirements for (a) an Enhanced Mechanism for MI Data Submission to OBIE and (b) the provision of MI Reporting Data from TPPs participating in the Open Banking Ecosystem in relation to the functionality introduced by the OBIE API Specifications.

The proposed new mechanism for MI Data Submission is an enhancement to the existing mechanism which is currently in place and used by ASPSPs to submit MI Reporting Data to OBIE. The enhanced MI Submission Mechanism will be available to be used by both ASPSPs and TPPs for the automated, where possible, submission of MI Data to OBIE.

The proposed new mechanism is directly related to the objective of this roadmap item which is the:

  • "timely" provision of MI to the Trustee and the ecosystem", and
  • the activity of "improved MI provision and reporting"​

as per the roadmap definition. The new data submission mechanism will allow ASPSPs and TPPs to submit MI data sets to OBIE in a timely manner, where required.

Please note that the MI Reporting from TPPs is not a direct requirement under the CMA Order or the Payment Services Regulations 2017. This MI is to be submitted to the Open Banking Implementation Entity (OBIE) by TPPs voluntarily, so as to enable the OBIE to measure the performance and adoption of the OBIE API Services offered by ASPSPs, as experienced by the receiving organisations and/or their end-users. 

It is however clearly mentioned in the roadmap item definition as "TPP-facing OB Standard to be implemented by TPPs (on a voluntary basis, supported by ICO Code if possible and if appropriate)."

The MI will be used to help OBIE to:

  1. understand the success and take-up of the Open Banking service
  2. assess the performance of the API services as they are perceived from the TPPs' perspective
  3. measure the drop out rates for each group of services
  4. forecast volumes and user growth to allow capacity planning and ensure sufficient support services, and 
  5. understand usage patterns for potential future product development.

Please refer to section 10 in the Appendix for the full roadmap item definition.

OBIE internal review

LBG, item #1

23. The need of an Enhanced Mechanism for MI Data Submission to OBIE

Added new section 3. The need of an Enhanced Mechanism for MI Data Submission to OBIE

3. The need of an Enhanced Mechanism for MI Data Submission to OBIE

3.1 Existing Reporting Challenges with ASPSPs

The following challenges exists with the  MI Reporting of ASPSPs to OBIE:

  • Incorrectly reported data: MI Reported data included in the reporting templates has included incorrect data on several occasions. OBIE has been working with the ASPSPs for over 2 years now to improve the quality of the data by introducing simple data validation rules in the template but these rules cannot pick up all cases.
  • Inconsistent data: There are cases where data included in one table of the reporting template does not match data reporting in another template. Thus, reported data is inconsistent generating confusion in relation to specific reports such as drop out rates.
  • Data reported too slow: On several occasions, MI data received by OBIE, is not able to produce useful analysis, insight and forecasting before reaching the mid of the next reporting month. This reduces the value of any of the analysis produced by OBIE and shared with the participating ASPSPs.     

3.2 Data Reporting Risks

  • Risk of Input Error: Human error can occur, which can create a risk of errors in the input process. In several cases, inaccuracies may be harmless, especially if they are in a field in a spreadsheet with little meaningful value.  However, there could be misinterpretations with data, especially if handwritten.
  • Risk of Incorrect Formatting: Data entry is arguably one of the most impressive organisational tools, when carried out correctly. With all information arranged accordingly, finding relevant data can be quick and easy. Sometimes though, manual input can present a problem where statistics and figures are filed wrongly, causing more time to be taken to rectify the problem. When tasked with a large range of information, manual in-putters can make the slightest of mistakes and key facts into the wrong fields, rendering them almost useless.
  • Increased Costs: Whilst manual data entry may seem like a relatively low cost operation on the face of things, this isn’t always the case. The many hidden costs of in-house entry can often outweigh the benefits of internal input. Input can be a time-consuming task requiring additional financial and time resources, which may be needed elsewhere in the business. As well as this, if an error does occur somewhere down the line, it may not be able to be instantly fixed, taking even more time away from core business activities.

Designing and implementing a new Enhanced Mechanism for MI Data Submission to OBIE will address the existing challenges and will eliminate some of the aforementioned risks. 

OBIE internal review

LBG, item #1

33. The need of an Enhanced Mechanism for MI Data Submission to OBIE

Renumbered sections as follows:

3→4, 4→5, 5→6, 6→7, 7→, 8→, 9→10, 10→11 

OBIE internal review
4

6.1 Enhanced MI Data Submission Mechanism (ASPSPs & TPPs)

Note: The detailed requirements for the Enhanced MI Data Submission Mechanism can be found in /wiki/spaces/WOR/pages/1530364944.

The following high level requirements are related to the enhanced MI Data Submission mechanism and are relevant for both ASPSPs and TPPs.

  • Reporting Mechanism: OBIE will be exploring the following options:
      • Fully Automated - API Based: Mechanism fully automated using API based processes over secure channels with endpoints called by participants (ASPSPs and TPPs) to submit the data directly to OBIE. The data will also be loaded automatically to OBIE's databases, consolidated and can be used to feed directly into predefined dashboards and reporting tables and graphs.
        • Pros: Requires less/no operational overheads, can support real-time (or near-real-time) reporting by participants, is secure and robust, can support automated data validation, is future proof.
        • Cons: Requires implementation by OBIE and participants (ASPSPs and TPPs) of API endpoints, requires technical resources to keep run and support, may not be widely adopted especially by smaller participants due to the cost of implementing and running, higher cost.
      • Other Reporting Mechanism Options: OBIE may also consider alternative options during the consultation period of the solution design specification. An initial set of proposed options can be found in the paper /wiki/spaces/WOR/pages/1528136088.

Note: OBIE may also consider alternative options during the consultation period of the solution design specification.

Note: Based on the received feedback, OBIE will be proposing a MI Data Submission design using Secure FTP (SFTP) as the delivery mechanism.

  • Reporting Data Format/Schema:  A reporting data schema already exists for the ASPSPs MI Reporting and a new schema will be produced as part of the TPP MI Reporting Specification to allow data reporting using the Enhanced MI Data Submission mechanism automated mechanisms for data exchange.
  • Use of Gateway Data Logs: Alternatively to using a data schema for all MI Reporting requirements, OBIE will also be looking to provide the capability of being able to receive redacted data logs directly from the participants' gateways. This will reduce the workload of formatting the data as per the appropriate data schema before submitting to OBIE, making it reporting simpler and easier. This approach may not be relevant to all required data, however, it is able to simplify certain groups of data required in high frequency, such as performance and availability data, volumetrics etc.  
  • Reporting Frequency: Reporting frequency will depend on the capabilities offered by the reporting mechanism (e.g. API vs SFTP vs other methods) and can vary between real-time and other reporting periods (e.g. monthly, fortnightly, weekly or daily) depending on the abilities of participants, the types of data to be reported (performance/availability, volumetric, authentication efficacy, PSU & Consent adoption, payment adoption etc.) and the use of the data by OBIE. The Enhanced MI Data Submission mechanism must be able to support both high frequency and normal frequency data submission. This will be discussed and agreed with participants.  during the consultation period.
  • Data Quality: OBIE will be encoding the endpoints, the TTP/TSP/ASPSP brand lists and other appropriate data in order to ensure high quality of reported data. This is in alignment with the existing MI Reporting Specification for ASPSPs. OBIE will also be looking to introduce data validation rules (within the MI Specifications and/or the reporting mechanism, where applicable), to ensure further data quality.

For more information on the in relation to the Enhanced MI Data Submission Mechanism, please refer to A2(c)(ii) Enhanced MI Data Submission Mechanism Solution Design - DRAFT-1

OBIE internal review
56.2 TPP MI Reporting Data (TPPs only)

The TPP MI Reporting Data high level requirements are shown below:

  • Categories: TPP MI Reporting will be split into 2 categories:

    1. Generic (Core): MI which is required by all participant TPPs 
    2. Service Specific: MI which is related specifically to the type of TPP service offered (e.g. for PISPs, AISPs, CBPIIs or even TSPs) and may be lower priority/nice to have or reported on ad-hoc basis, as and when required for analysis of specific issues. This MI is for future consideration and will not be included in the initial version of the TPP MI Specification. 
  • Generic (Core) MI will include the following types of reporting data elements:
    • Performance data: This data set will include measurements of the average response times of the various API endpoints and also the end-to-end service timings as experienced by TPPs and their PSUs.
    • Volumetric data: This data set will include measurements of the volumes of API endpoints calls including successes, failures, rejections, no-authorisations etc. TPPs will be reporting which ASPSPs those endpoints are made to, so that will be able to reconcile volumes against volumes reported from the ASPSPs.
    • Auth Efficacy data (Drop-out rates): This data set will include 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.
    • PSU & Consent Adoption data: This data set will include 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.
  • Service Specific MI will include the following types of reporting data elements:
    • PISP Only:
      • Payments Adoption data: This data set specific for PISPs, will include payment initiation related data per payment type including the number of FPS, Bacs, CHAPS, SOs, and international payments.
      • Other: Payment Status, Payment SCA Exemptions, Payment Refunds 
    • AISP Only: Revocation Notifications from ASPSPs, Corporate Account Access, 90-Days Re-authentication
  • Reporting Granularity:  For some of the data elements such as performance and volumetrics, OBIE is looking to introduce hourly reporting granularity instead of daily (which is what is used by ASPSPs split between core and non-core business hours). This will allow OBIE to produce intra-day profiling of the usage of Open Banking APIs for the different services, per TPP and per ASPSP. Obviously, if real-time reporting is introduced, this granularity may be even finer.
  • TPP/TSP/ASPSP level: OBIE will be introducing granularity of both reporting TPP and TSP at the endpoint level and also at the ASPSP level.
  • Free-format field: OBIE is considering adding free format text entries in the reporting fields for the opportunity of TPPs raising specific issues or providing comments in freed text format. This data element will be optional.
  • Data Sharing/Consuming: OBIE will be using the data internally for data analysis, insight and forecasting. Moreover, OBIE will be able to share with each TPP the historical data of their own submissions. However, OBIE will be consolidating and anonymising all the data if any reports based on this are to be shared with other TPPs and the wider ecosystem. OBIE may request permission from the TPPs if data is to be used in a different manner.
  • Alignment to CEF Framework: OBIE will also be looking to receive the TPP MI Reporting data labelled in alignment to the Consumer Evaluation Framework especially in relation to the defined outcome area and the directly related propositions.
  • Service Specific MI will include the following types of reporting data elements:
    • PISP Only:
      • Payments Adoption data: This data set specific for PISPs, will include payment initiation related data per payment type including the number of FPS, Bacs, CHAPS, SOs, and international payments.
      • Other: Payment Status, Payment SCA Exemptions, Payment Refunds 
    • AISP Only: Revocation Notifications from ASPSPs, Corporate Account Access, 90-Days Re-authentication

Note: Service Specific MI is for future consideration and will not be included in the initial version of the TPP MI Specification. It is mentioned here for completeness. 

OBIE internal review
67. Regulatory and Legal Considerations

The CMA Order contains the following points in relation to MI reporting: 

  • Schedule 1, Article 2(j), states that it is the responsibility of the OBIE Trustee to "monitor compliance by the Providers with the Order". 
  • Article 14.1 states that Providers must make up to date PCA and BCA transaction data sets continuously available without charge, for read and write access in accordance with the relevant provisions of the Read/Write Data Standard. 

Thus, while there is a clear regulatory requirement of the Order for the Providers to allow the OBIE Trustee to monitor their compliance, there is no requirement for the Consumers of the API Services, i.e. the TPPs. However, receiving data from TPPs would assist the OBIE Trustee not only in the task of monitoring the compliance of the Order, but also the effectiveness of the CMA Order to the ecosystem, its competitiveness and the positive impact to the business and consumer PSUs. 

In conclusion, TPP MI Reporting is voluntary for TPPs but essential quite important for OBIE to be able to improve the services offered to the ecosystem.  

OBIE internal review
7

8.4 Reference documents

OBIE internal review
8

8.1 Detailed Requirements

Note: For the detailed requirements of the Enhanced MI Data Submission Mechanism (ASPSPs & TPPs), please refer to A2(c)(ii) Enhanced MI Data Submission Mechanism Solution Design - DRAFT-1 /wiki/spaces/WOR/pages/1530364944OBIE internal review
9

9.1.1.1 Overall Performance

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.

OBIE internal review
109.1.1.1 Overall Performance

Added new data field as follows:

  • ID: 21
  • Description: CEF Outcome Area
  • MoSCoW: Should
  • Data Usage: As Is or Consolidated
OBIE internal review
11

9.1.1.1 Overall Performance,

item #6

Modified data field #6 as follows:

  • ID: 6
  • Description: Retail or Business PSU
  • MoSCoW: Must Should
  • Data Usage: As Is or Consolidated

OBIE internal review

TrueLayer, item#3

12

9.1.1.1 Overall Performance,

item #12

Modified data field #12 as follows:

  • ID: 12
  • Description: API Calls generating Rejection Status
  • MoSCoW: Must Should
  • Data Usage: As Is or Consolidated

OBIE internal review

TrueLayer, item#3

13

9.1.1.2 End-to-End Response Times

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.

OBIE internal review
14

9.1.1.2 End-to-End Response Times

item #6

Modified data field #6 as follows:

  • ID: 6
  • Description: Retail or Business PSU
  • MoSCoW: Must Should
  • Data Usage: As Is or Consolidated

OBIE internal review

TrueLayer, item#3

15

9.1.1.2 End-to-End Response Times

item #10

Modified data field #10 as follows:

  • ID: 10
  • Description: Total TTLB Response Time (Time to Last Byte) Total Time Period Duration 
  • MoSCoW: Must
  • Data Usage: As Is or Consolidated

OBIE internal review

169.1.1.2 End-to-End Response Times

Corrected data field numbering as follows:

12→11, 13→12, 

OBIE internal review
179.1.1.2 End-to-End Response Times

Added new data field as follows:

  • ID: 13
  • Description: CEF Outcome Area
  • MoSCoW: Should
  • Data Usage: As Is or Consolidated
OBIE internal review
18

9.1.1.3 Auth Efficacy

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.

OBIE internal review
199.1.1.3 Auth Efficacy

Added new data field as follows:

  • ID: 13
  • Description: CEF Outcome Area
  • MoSCoW: Should
  • Data Usage: As Is or Consolidated
OBIE internal review
20

9.1.1.4 PSU and Consent 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.

OBIE internal review
21

9.1.1.4 PSU and Consent Adoption

item #5

Modified data field #5 as follows:

  • ID: 6
  • Description: Retail or Business PSUs
  • MoSCoW: Must Should
  • Data Usage: As Is or Consolidated

OBIE internal review

TrueLayer, item#3

229.1.1.4 PSU and Consent Adoption

Added new data field as follows:

  • ID: 18
  • Description: CEF Outcome Area
  • MoSCoW: Should
  • Data Usage: As Is or Consolidated
OBIE internal review
23

9.1.2 Service Specific MI

9.1.2 Service Specific MI (FUTURE CONSIDERATION)

Note: Service Specific MI is for future consideration and will not be included in the initial version of the TPP MI Specification. It is mentioned here for completeness. 

OBIE internal review