P1 • Open Data for standardised back-book products (PCA & BCA)

• Version Control
  • Introduction
• Roadmap Definition
• Regulations
  • Regulatory references
  • Regulatory requirements
• Use cases
• Scope
  • In scope
• Comments
• Not in scope
• Considerations
  • Constraints
  • Dependencies
  • Assumptions
• How we will measure adoption

Version Control

Introduction

The purpose of this paper

The purpose of this paper is to define the overall proposition for item P1, so that participants (ASPSPs and TPPs) and stakeholders (FCA, HMT, CMA) are clear about what is and is not in scope for this item, and how this will support regulatory requirements and key use cases.

Roadmap Definition

The following table is taken ‘as-is’ from the published roadmap (https://www.openbanking.org.uk/wpcore/wp-content/uploads/2017/11/FAO-CMA_Proposed-Amendments-to-Agreed-Arrangements_v_final-1.pdf):

Regulations

Regulatory references

The requirement to provide product information for back-book products was excluded from the March 2017 delivery.   The published roadmap requires the development of back-book product data functionality in existing OB API standards.

• The CMA Order does not explicitly specify product reference data for back-book products but provides detailed requirements for front book PCA and BCA products. OBIE has taken these requirements as the starting point for back product reference data, as outlined below: The Retail Banking Market Investigation Order 2017

Providers shall release and make continuously available without charge, in accordance with the Read-only Data Standard:

12.1.2 Product information, before the application of any negotiated changes, for each of their on-sale PCA products & BCA products, which shall include, where relevant:

(a) product prices including credit interest;

(b) all charges, including the interest rates (credit and debit) which apply to the product, the fees and charges which may apply to activity on the account, and the circumstances in which these charges apply;

(c) benefits, including credit interest and constituent parts of packaged accounts;

(d) MMC once MMCs have been introduced in accordance with Part 7;

(e) terms and conditions;

(f) customer eligibility criteria; and

(g) any other product information reasonably required by the Implementation Trustee and agreed by the CMA.

12.4.1 ‘PCA products’ include:

(a) any PCA whether or not it includes an overdraft facility;

(b) Basic Bank Accounts;

(c) packaged accounts;

(d) reward accounts;

(e) student or graduate accounts;

(f) youth accounts; and

(g) any other product reasonably specified by the Implementation Trustee provided it falls within the terms of reference of the CMA’s retail banking market investigation and the AECs identified and has been agreed upon by the CMA.

12.4.2 ‘BCA products’ include:

(a) BCAs;

(b) Business Overdrafts; and

(c) any other product reasonably specified by the Implementation Trustee provided it falls within the terms of reference of the CMA’s retail banking market investigation and the AECs identified and has been agreed upon by the CMA.

Summary of responses to formal consultation

Back book products: One respondent expressed the view that the ruling of back book products out of the scope of the release of product and reference information from March 2017 could render the remedy ineffective since customers with such products would not be able to compare them with products currently being marketed.

CMA response:

Back book products were excluded from the scope of the release of product and reference information following representations during the informal consultation.

Although back book products are excluded from the product and reference data to be released from March 2017 they are not excluded from the obligation to share transaction data that will be adopted from January 2018. Once these obligations are in force we expect tools to be developed to enable customers to compare the cost of their present account (including back book products) with new ones on the basis of actual and equivalent usage. While there may be benefits from including back book products in the March 2017 release, for example for customers not wishing to share their transaction data, we concluded that the cost of doing so would outweigh the benefits.

Business current account and personal current account pricing analysis

This paper summarises the key factors which affect pricing for PCA and BCA accounts and gives real-world examples based on selected customer profiles across all the major UK banks.

Regulatory requirements

The Open Data standard which went live in March 2017 covered all standard front book accounts for the CMA9 in the UK. The roadmap requires product reference data to be made available. Neither the roadmap nor CMA order specifies the requirements for reference data for back-book products. This proposition considers the use of the same product reference requirements as used front book BCA/PCA. Recent analysis has revealed that there are approx. 72 million PCA and BCA accounts in the UK across the CMA9. Of these, over 8 million are standard back book accounts, and less than 1m are negotiated or bespoke. The OBIE interpretation of this roadmap item is that it is designed to cater for these 8 million standard back book accounts, which were not included in the Mar 2017 release. But accounts with negotiated or bespoke pricing are not covered by the CMA Order.

Use cases

OBIE has considered real-world use cases to help define the requirements of this roadmap item.

• As a Price Comparison Service Provider, I want to provide recommendations for alternative accounts in the market using the customer’s actual account usage behaviour and actual account pricing structure, so that the recommendation identifies potential savings that could be made if the customer switched to another account.
• As a TPP, I want to show the account holder the current fees, charges and features on his/her account, so that they can understand these fees, charges and features better.

These use cases make no distinction as to whether the PSU’s account is a front book, back book, or indeed negotiated/bespoke. Hence the design of this item should enable ASPSPs (including the CMA9) to cater for back book accounts in order to meet the requirements for the use cases stated above. This design should also allow ASPSPs to cater for customers on negotiated/bespoke accounts, albeit this may be optional for ASPSPs to support.

Version 1 of the Read/Write API specifications includes a ‘products’ endpoint within the Account Information and Transaction API. This allows a TPP (with PSU consent) to access the PSU’s account and retrieve the product ID. This ID can then be used to reference the corresponding product in the open data standard. So for any customers who have a product defined in the open data standard, the requirements and use cases can be met.

The CMA9 are already populating the open data standard for all standard front book PCA and BCA accounts. However this is not the case for standard back book PCA and BCA accounts, and there are several reasons why an ASPSP may not be able to populate the open data standard with back book products:

• The open data standard is very detailed and not all details exist for some older products.
• The granular detail in this standard may not be suitable for all back-book products and would require significant analysis by OBIE and potentially result in a more complex data model to cater for all the variables.
• Some brands may have a very large number of back-book products spread across a relatively small number of PSUs.

The combination of these means that the work required to produce and populate the open data standard with back-book products could be significant.

Scope

In scope

The scope of this roadmap item is to extend the coverage of the existing open data standard as follows:

• Inclusion of all standardised back book accounts.
• As per the current open data standard, limited to UK sterling PCA and BCA accounts.

OBIE has conducted a series of workshops (Product Endpoint Initial Workshop, PCA Workshop & BCA Workshop ) with TPPs and ASPSPs to define the key subset price variables that are most useful for price comparison and can be made available by the ASPSPs. This design is based on a smaller subset of the full PCA and BCA model and is more suited to back book products (see below).

Furthermore, we agreed (see TDA decision 039) that this model would sit in the ‘products’ endpoint for version 2.x of the Read/Write API standard. In combination with the existing product ID, this would allow an ASPSP to support either or both of the following models:

• Referential model: where the ASPSP populates the open data standard with all standard back-book products, and the TPP looks up the product details for each PSU from open data.
• Direct model: where the ASPSP populates this smaller subset of data in the products endpoint, and the TPP has access to all product data directly from the products endpoint.

Some ASPSPs will use one model and some may use both, depending on the PSU and the product. In any case, any data provided by the direct model should take precedence.

In both cases, the TPP will need to be a regulated AISP to access the product’s endpoint.

For PCA:

For BCA:

Comments

Negotiated/bespoke products are not mandated in release 2. However, the design should cater for these accounts and thus allow ASPSPs to optionally provide the relevant pricing information for PSUs on such accounts.

Not in scope

The following product types are out of scope for this roadmap item:

• Any non-sterling accounts.
• Some third-party (e.g. charity) accounts.
• Corporate and private banking accounts.
• Credit cards (personal or corporate).
• Charge cards.
• Loans and mortgages (personal loans, SME loans, enterprise financial guarantee loans, managed loans, partnership capital loans, property development loans, personal mortgages, commercial mortgages, or investment property loans).

Considerations

Constraints

Some ASPSPs may still have difficulty sourcing/providing detailed pricing information for some (e.g. older) back book products.

Dependencies

Access to the ‘products’ endpoint will only be given to registered and enrolled AISPs (i.e. this is not open data as it relates to the specific product for a defined PSU).

The suitability of the design and data quality to enable comparison/switching will be evaluated in roadmap item P14.

Assumptions

• This item is mandatory for the CMA9.
• Other (non-CMA9) ASPSPs may also choose to opt-in to support this item/standard.
• Some ASPSPs may choose to include negotiated/bespoke accounts.

How we will measure adoption

The following metrics will be required to measure adoption:

1. Number of TPPs using products endpoint.
2. Volume of failures for access to this endpoint.
3. Volume of successful accesses from this endpoint.
4. Uplift in switching metrics since launch of P1.