Propositions

P20 • PSD2 in-scope accounts (sterling)

The purpose of this paper is to define the overall proposition for item P20 (PSD2 in scope accounts, sterling), 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.

Other pages in this section

Version Control

VersionDateAuthor(s)Comments
0.119 Dec 2017 OBIE API Delivery TeamInitial draft for presentation to the Read/Write working group.
0.221 Dec 2017 OBIE API Delivery TeamUpdates based on feedback from workshop on 19 Dec 2017 and 20 Dec 2017 and from OBIE Regulatory/Legal team.
0.305 Jan 2018 OBIE API Delivery TeamUpdate based on feedback from meeting with Regulatory & Legal team on 04 Jan 2018 
0.409 Jan 2018 OBIE API Delivery TeamMinor update to reflect communication to IESG
0.518 Jan 2018 OBIE API Delivery TeamMinor update to change scope table heading from Definition to Description and clarification that non GBP accounts and paper/pdf statements are out of scope.
0.608 Feb 2018 OBIE API Delivery TeamFeedback and Clarifications
1.022 Feb 2018 OBIE API Delivery TeamApproved as the scope at IESG.

Introduction

The purpose of this paper is to define the overall proposition for item P20 (PSD2 in scope accounts, sterling), 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 R/W APIs to cover the full set of PSD2 sterling denominated products not covered under the Order (including but not limited to credit cards, currency accounts, charge cards, e-wallets, pre-paid accounts and payments enabled savings, deposit, loan and mortgage products) and comprehensively fulfilling the functional requirements of PSD2

Key activities:
• A discovery phase by the OBIE to understand the variety of payment accounts in scope and used in practice, 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 as soon as is practical and no later than Release 4
Regulatory alignment:
• Fulfils the requirements of PSD2 through OB standards
Open Banking adoption:
• Extends coverage of OB Standards to cards providers seeking PSD2 solutions
Consumer / SME utility:
• Consumers would be able to access their full breadth of payments activity and benefit from comprehensive AIS and PIS services
Security / Integrity:
• Consumers would be able to access their data without credential sharing and access their payments without putting cards on file
PSD2

Regulations

Regulatory references

The following regulatory references are relevant when considering the scope of item P20:

PSR Reg 1(2)(Interpretation)

‘payment account’ means an account held in the name of one or more payment service users which is used for the execution of payment transactions

PSR 2017 Reg69(1) (Access to payment accounts for payment initiation services) states:

This regulation applies only in relation to a payment account which is accessible online.

PSR 2017 Reg 70(1)(Access to payment accounts for account information services) states:

This regulation applies only in relation to a payment account which is accessible online.

FCA Approach Document and final Handbook changes 17.14 and 17.15

17.14 The meaning of ‘accessible online’ is not defined under the PSRs 2017. In our view, an account is accessible online if the ASPSP offers online banking services in relation to that account. Online banking services may be provided through websites or applications, and may be accessible using a desktop computer, mobile phone, tablet or any other such device. Whether an account is accessible online should not be dependent on whether a particular customer has chosen to activate online banking services with the ASPSP. As a result, an ASPSP should not deny an AISP or PISP access to a customer’s account or refuse to give confirmation of availability of funds to a CBPII on the basis that the customer has not registered for online banking. The customer may, however, need to activate online banking services before they can use AIS or PIS, if they do not already have the security credentials for use in the ASPSP’s authentication procedures.

17.15 The purposes for which the specific account can be accessed online also needs to be considered when determining whether an account is ‘accessible online’. Whether regulations 68, 69 and 70 of the PSRs 2017 apply to a payment account will partly depend on what the account holding customer could do with that account online. In our view, an account which is available online on a ‘view only’ basis, but without any payment functionality, would not be ‘accessible online’ for the purposes of PIS. It would, however, be ‘accessible online’ for the purposes of AIS and confirmation of availability of funds to a CBPII.

HMT response to consultation:

7.25 The government intends to maintain the approach set out in the consultation document, regarding the accounts in scope of the AISP/PISP regime (namely access must be provided to all online payment accounts).

Again, in line with what the government set out in the consultation document, ASPSPs will only be expected to provide equivalent access to that available online to customers. Therefore if consumers cannot initiate a payment from their online credit card account, PISPs cannot initiate a payment either (and therefore have no right of access).

Equally if there is no online account available (as is the case for many gift cards) there is no requirement for access to be provided.

CMA order:

10.1.2 Both read and write access, which allows a third party to access account information or initiate a payment on behalf of the customer (subject to the customer’s explicit consent), for data set out in Article 14 (the ‘Read/Write Data Standard’) and which has the features and elements necessary to enable Providers to comply with the requirements to provide access to accounts subject to this Part 2 of the Order under PSD2 .

10.2 Neither the Read-only Data Standard nor the Read/Write Data Standard shall include provisions that are incompatible with the requirements in PSD2.

Regulatory requirements

For Account Information Services:

The OBIE interpretation is that the key regulatory requirements are:

For Payment Initiation Services:

The above regulatory requirements do not fully define the functionality needed to meet the needs of AISPs and PISPs, especially to enable the development of innovative new products using multiple payment accounts. The following are some of the key/high priority use cases which corroborate the definition and rationale as stated in the roadmap item above.   

Use Cases

Read API with extended accounts in scope

Scope

In scope

Based on the regulatory requirements and customer use cases above, the following items are considered in scope for P20. In all cases this covers GPB accounts/payments (as other currencies are covered by P10 and P21).

Account TypeDescriptionAISPIS
Current accountsPersonal and business current accountsYY
Payments enabled flexible savings accountsFlexible Savings are instant access account which offer interest, where customer can put in or take out money whenever they like.
Payments are made either to a linked current account (Post Office Money, AA) or to any other account (HSBC Flexible Saver) 
YY
Payments enabled deposit accountsDeposit accounts which allow initiation of payments from an online channel of the ASPSPYY
Payments enabled loan accountsLoan accounts which allow initiation of payments from an online channel of the ASPSPYY
Payments enabled mortgage accountsCurrent Account mortgages which combine customer’s mortgage and current account to give one overall balance.
Customers can use these accounts to make payments from the online channel and some issuers will also issue a debit card
YY
e-money accountsE-money accounts represent cash value that is stored in an account.
Products supported by e-money accounts could be pre-paid accounts with virtual account number-sort codes, pre-paid cards.
YY/N
(depending on
the e-money product)
Credit card accountsCredit card account is a payment account, which is available online, with the card issuing entity.
For a PSU there could be multiple credit cards linked to the same card account (e.g. MBNA Visa and Amex cards linked to the same account)
PSU could have have multiple card accounts (Visa, MasterCard) with the same issuer.
A credit card is a credit facility that requires a repayment of a minimum amount each month
Y N
Charge card accountsA charge card is a card that requires payment in full every month. A charge card is a credit facility that requires repayment of balance in full every month.YN

Notes on Payment Initiation Service:

Comments

The following additional payment types are not currently envisaged for release 2: Balance transfer from one card account to another card account.

The next steps are to clarify and manage under change control in a future release or include in current release subject to approval through the proper governance process.

Not in scope

The following items are NOT in scope for item P20, as they are either outside the scope of PSD2 and the CMA Order, or they are covered by a subsequent roadmap item in release 3 or 4:

  1. API access to paper/PDF statements are considered out of scope for a PSD2 read API.
  2. Non-GBP payments and accounts, including Euro and FX (see item P10 and P21).
  3. Bulk/batch payments (see item P11).
  4. Accounts where multiple authorisations are required (see item P13).
  5. Corporate accounts (see item P22).
  6. Digital wallets (Apple Pay, Samsung Pay) where the customer adds cards from multiple issuers.
  7. Store value accounts with limited network capability (i.e. which can be used only at specific places e.g. gift cards, fuel cards, membership cards, public transport cards etc.).

Considerations

Constraints

All accounts need to be accessible through the ASPSP online channel.

Dependencies

TBC

Assumptions

For Read APIs:

For Write APIs:

How we will measure adoption

The following metrics will be required to measure adoption:

  1. Number of TPPs utilising each of the above payment account types for Read
  2. Number of TPPs utilising each of the above payment account types for Write, where applicable
  3. Volume of each Read API endpoint calls for each of the payment account types
  4. Volume of each Write API endpoint calls for each of the payment account types, where applicable
  5. Volume of successful accesses for each of the above payment account types
  6. Volume of successful transactions generated for each of the above payment account types, where applicable
  7. Volume of failed accesses by type of failure for each of the above payment account types
  8. Volume of failed transactions by type generated for each of the above payment account types, where applicable