Version Control

Overview

This specification includes all relevant artefacts for the Open Data Personal Current Account (PCA) API Specification.

Currently, price comparison websites have to obtain their PCA product data either via bank proprietary APIs, via information collected by dedicated data capture agencies or via "screen scraping" (i.e. capturing product web page information and writing scripts to extract relevant data). This work is complex and prone to error, so having a standard API would make the data capture side much easier and allow more third party providers to provide applications that could target particular consumer markets.

This endpoint can contain multiple brands owned by a particular banking group. Each brand can own multiple PCA products.

PCA

This section covers PCA attributes that will change only under rare circumstances (see Core Product section below for additional attributes that will be updated regularly). In this section the following information can be provided:-

• Product Name i.e. the name marketed to the consumers.
• Identification is the unique id created by the financial institution to internally define the product
• Segment - allows specification of the type of product e.g. basic, regular, premium

MarketingState

Within our design, we have a concept of a "marketing state" for the product. This concept is required because for any "On Sale" PCA product:-

1. The PCA may provide a different offering to the account holder the longer that they hold a particular PCA
2. The bank can change any of the PCA attributes over time. 

We'll illustrate this with a complex example. 

CMA9Bank has a PCA product that was first advertised on 1/1/2017 and has the following features currently:-

1. If the accountholder takes the product, they are offered a promotional interest rate of 5% for 1st 9 months, then 2% for next 12 months and then it reverts back to the standard variable rate (currently 0%).
   
   

The original marketing states can be shown as follows:-

On 17th July, CMA9Bank are going to change the offer, so that only 3% is paid in the 1st 9 months. The marketing states on 16th July will look like this:-

And on the 17th July, the marketing states will look like this:-

Notes:

1. PredecessorID is used to sequence the creditinterest states offered to the customer when they take out the PCA, it does not record change history.
2. FirstMarketedDate and LastMarketedDate cover the period when the particular marketing state was advertised to the customer.
3. CMA9 Banks only have to provide information for current (and known future, if they wish) marketing states. There is no open data requirement to provide an audit history of all marketing states that ever applied to the PCA. When the future marketing state becomes the current marketing state, the original marketing state information no longer needs to be published.
4. When CP1 Marketing state is replaced by CP3 Marketing state, the PredecessorID in CP2 will also need to be updated to point to CP3, as shown.
5. The Identification column is simply for internal bank use. The ID column is required so that we can sequence states, and also so that any applications that need to link an accountholder's PCA with the particular state that their account is in, can do this. e.g. For closed data, there is a requirement to compare an accountholders existing account details with those on the open market. If the accountholder has just opened the account, in the example above, they'd be in the 1st promotional state, if they have opened the account 10 months ago, they'd be in the 2nd promotional state. If they'd opened the account more than 21 months ago, they'd be in the regular state. By using a combination of the product id and the marketing state id, we can precisely link a particular accountholder's account with the current interest rate that is being applied to that account. 

Core Product

This sections includes information that can change relatively often. Information to be provided includes:-

• Product URL allows a link to the financial institution's website where more detail about the product can be found
• URL to the product's terms & conditions
• Sales Access Channels cover all of the channels by which a customer can be sold a BCA 
• Servicing Access Channels cover all of the channels by which a customer can receive service for their BCA. Note: This covers servicing of all aspects of the BCA. Some aspects may not be serviceable via certain channels
• MonthlyMaximumCharge (MMC) is a measure of the maximum amount that a consumer may be charged per month, when they exceed their agreed credit limit. There is currently strict definition of which charges fall in to this category, with grey areas such as "EmergencyBorrowing" potentially being in scope. The CMA9 have to calculate an MMC for each PCA product by August 2017, and provide the details as to how they calculated these.

Credit Interest

In this section, information about the interest rates that are payable to the consumer are listed. Interest rates are typically standard variable rates, with rates potentially changing many times during the course of the products. In addition to the 'Regular' standard variable rates, some PCA products also provide for more attractive 'Promotion' interest rates which are fixed for a relatively short duration. 

Another feature of interest rates is that certain PCA products will pay more attractive rates, as the amount deposited and maintained in the account increases.

This section has been designed to allow the implementer to provide whole or tiered interest rates.

Currently, most PCA price comparison websites focus on the promotional or regular interest rate (where there is no promotion) as their main mechanism for providing a comparison of PCA products.

Overdraft/Borrowing

The Maximum Monthly Charge (MMC) focuses on fees & charges due to unauthorised borrowing. Price comparison websites are currently more focussed on details of arranged overdraft rates and accompanying fees & charges.  There are also grey areas e.g. emergency borrowing which is a short term provision for situations where a customer has exceeded their arranged overdraft or authorised credit limit but only by a small amount and only for a short period.

As such, this section has been named 'Overdraft/Borrowing' so as to cover situations of authorised borrowing e.g. an Arranged Overdraft and unauthorised borrowing e.g. customer exceeding a credit limit by more than a buffer amount and with no arranged overdraft or emergency borrowing facility in place. An Authorised Indicator flag allows the implementer to indicate whether the borrowing is authorised or not.

Details as to any capping (i.e. maximum amount that can be charged to a customer for a particular period) for any fee/charge can also be specified.

Eligibility

In this section, criteria such as residency and age restrictions that are necessary for opening an account are provided. Note eligibility criteria for features & benefits are treated in that section. 

Features & Benefits

In this section, information about any inherent product features or value-added benefits (whether they're charged or not) can be captured. Benefits can also be grouped together e.g. if a package of benefits is supplied. For any benefits group, benefit details may be individually added or notes simply added to the benefits group. 

For a benefits group or for individual benefits, any eligibility criteria required to obtain that benefit can be specified as notes.

Other Fees & Charges 

Fees & Charges that a customer has to pay can be specified for Borrowing and in the Features & Benefits section. The long tail of additional fees & charges that are not associated to either of those 2 areas can be specified in this section.

Details as to any capping (i.e. maximum amount that can be charged to a customer for a particular period) for any fee/charge can also be specified in this section.

Specification

The following UML Class Diagram provides the hierarchical structure of the message in a graphical form, which is easier to digest.

• Data Dictionary - provides detailed descriptions for each field in the message specification along with the associated code lists, constraints and other technical details such as cardinality, any pattern constraints, min, max length etc.
• Swagger - the API specification written using the Swagger API specification format.
  
  

Compliance Report

• Compliance Report - highlights changes made to fields & datatypes from v1.x.

Message Implementation Guide

Purpose

The message implementation guide (MIG) is designed to assist the implementer of the messaging specification by providing worked examples as to how the message fields should be completed in different scenarios.

The intention is that this will better ensure consistency. This guide should be read alongside the data dictionary which provides fuller information about the rules, constraints and guidelines that should be adhered to when populating the fields.

PCA is particularly challenging due to the different types of account that are covered:-

• Youth/Young Adult, Student, Graduate
• Basic, Standard, Premium – Note: Premium is a marketing term for a PCA that a bank feels is of higher value than the Standard offering. They are not legally distinguishable form a Standard PCA.
• Reward, Packaged.

Different accounts have been chosen,  based on how fully they test each section of the design.

OtherFeesAndCharges isn’t covered by the use cases due to these currently being bank proprietary fees/charges and not standardised currently. Key standardised Fees and Charges covering overdraft and benefits are covered in the relevant examples stated above, however.

Format Notation

The format that we use in this document for field value assignment is:-

[] enclose a set of field values.

Where there are multiple records for a particular field, we depict this as [<record 1 value1>,< record 1 value2>…<recordn valuen>], whilst where we are showing that there is 1 field value in 1 record, and another field value in a 2nd record, I depict this as [<record1 value1>],[<record 2 value 1>],[<record 3 value 3>]

, seperates individual field values within a field value set.

“ surrounds a text or date field value.

Implementation Notes

Before implementing the message standard, it is very useful browsing price comparison websites (e.g. https://www.moneysupermarket.com/current-accounts/, https://www.comparethemarket.com/current-accounts/) to understand how implementation of our standard by the CMA9 banks would help to more easily facilitate provision of information used on those sites.

Currently, price comparison websites have to obtain their PCA product data either via bank proprietary APIs, via information collected by dedicated data capture agencies or via "screen scraping" (i.e. capturing product web page information and writing scripts to extract relevant data). This work is complex and prone to error, so having a standard API would make the data capture side much easier and allow more third party providers to provide applications that could target particular consumer markets.