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

Version Control 

Version
Date
Author(s)
Comments
0.1 

OBIE API Delivery Team

Initial draft for review

0.2 OBIE API Delivery TeamMinor update to reflect communication to IESG
0.3 OBIE API Delivery TeamClarification that negotiated/bespoke accounts are not a CMA Order requirement
0.4 OBIE API Delivery Team

Added feedback from PAG on  to include clarification that features and benefit details are covered in the designs, and data quality and suitability for comparison/switching will be evaluated in roadmap item P14.

0.5 OBIE API Delivery TeamOBIE R&L review 
1.0 OBIE API Delivery TeamApproved as the scope at IESG.

Introduction

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):

DescriptionRationaleAligns with

Scope Item description:

  • Extension of OB API functionality to cover back-book product reference data for standardised PCA and BCA

Key activities:

  • A discovery phase by the OBIE to understand the variety of back book accounts, understand gaps in existing functionality and modifications required to the exiting standards
  • The development of standards by the OBIE for the products and functionality referred to above
  • The implementation of those standards by the CMA9 for Release 2

Regulatory alignment:

  • Fulfils the requirements of the Order

Open Banking adoption:

  • Extends functionality of OB Standards product comparison use cases to a material proportion of the CMA9 account base

Consumer / SME utility:

  • Consumers would be able to benefit from current account product comparison
CMA Order

Regulations

Regulatory references

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

  • The CMA Order does not explicitly specify product reference data for backbook 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’ includes:

(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 by the CMA.

12.4.2 ‘BCA products’ includes:

(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 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 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 backbook 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 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 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 include 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 backbook 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 backbook products spread across a relatively small number of PSUs.

The combination of these mean that the work required to produce and populate the open data standard with backbook products could be significant.

Scope

In scope

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

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

OBIE has conducted a series of workshops (Product Endpoint Initial WorkshopPCA WorkshopBCA 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 backbook 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 products endpoint.


For PCA:

Product Section

Fields to be included (as applicable)

PCA 

  • Name
  • Open Data Product ID (Mandatory, if product info is available on Open Data PCA API)
  • ProductType (“PCA”)
  • MonthlyMaximumCharge (Mandatory for “front book” products)

PCAMarketingState

Optional - Sections will only include current state information, so this section is not required

CreditInterest

  • TierBandSet fields  (excluding credit interest eligibility).
  • All TierBand fields

Note: Only current state credit interest information is required.

Overdraft

  • All TierBandSet fields (including OverdraftFeesAndCharges)
  • All TierBand fields (including OverdraftFeesAndCharges).

Note: Only current state information is required.

Eligibility

None – Eligibility criteria met when PCA was sold unlikely to be reliable.

FeaturesAndBenefits

Optional – The value of a particular feature and benefit to an accountholder is dependent on their use of that benefit and whether they met eligibility criteria. Certain benefits may be provided by external suppliers making it difficult to provide real time info. Relevant general features & benefits info can be obtained from Open Data API for “front book” products.

The details of these features and benefits will be addressed in the designs.

OtherFeesAndCharges

  • Periodic Fee (i.e. the service charge)

For BCA:

Product Section

Fields to be included

BCA 

  • Name
  • ProductType (“BCA”)
  • Product Segment (e.g. “Startup”,”Switcher”,”)
  • Open Data Product ID (Mandatory, if product info is available on Open Data BCA API)
  • Fee-free period

BCAMarketingState

Optional – Sections will only include current state information, so this section is not required

CreditInterest

  • TierBandSet fields  (excluding credit interest eligibility).
  • All TierBand fields

Note: Only current state credit interest information is required. Where the interest rate(s) have been negotiated, the actual rates applied to the account should be provided.

Overdraft

  • All TierBandSet fields (including OverdraftFeesAndCharges)
  • All TierBand fields (including OverdraftFeesAndCharges).

Note: Only current state information is required. Where the overdraft rate(s) have been negotiated, the actual rates applied to the account should be provided.

Eligibility

None – Whether an organisation is eligible for other products cannot be determined by looking at existing product eligibility e.g. criteria for a startup can vary from bank to bank.

FeaturesAndBenefits

Optional  – The value of a particular feature and benefit to an accountholder is dependent on their use of that benefit and whether they met eligibility criteria. Features & benefits are less significant in BCA market than for PCA.

The details of these features and benefits will be addressed in the designs.

OtherFeesAndCharges

  • With BCA, there are substantially more other fees & charges than are applicable to PCA account holders.

  • Prior to OBIE being formed, the CMA asked the 9 banks to provide a set of fees & charges that would allow for a comparison between banks, the results of which are documented in the Business current account and personal current account pricing analysis. The comparison included the following Fee Types, which we think are relevant, all of which are domestic transactions. As well as fee comparison information provided by the banks to the CMA9, there are additionally tariff comparison calculators provided by some of the banks that allow a BCA holder the ability to determine which bank product would provide them with the lowest set of charges.

  • Electronic: Auto credit, Bill payment, Debit card payment, Direct debit, Standing Order

  • Branch/Other: Pay in (Counter), Deposit (Cheque), Issue (Cheque),  Withdrawal (Counter), Cash In, Cash Out (Counter), Cash Out (ATM)

  • However, our analysis is that the basket of fees is a weighted average provided as a one-off activity and it would be difficult for the banks to supply fees/charges for these business activities in a real time API, due to banks charging fees at different levels of granularity today and fee standardisation being required. Although comparative pricing is highlighted as a key driver of the open banking initiative, without fee standardisation, the complexity of comparing fees is likely to deter customers from considering switching.

  • We conclude that as with PCA, the periodic fee is the most common “Other” fee and charge that BCA price comparison websites provide today.

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