P20 • PSD2 in-scope accounts (sterling)

Version Control

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

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:

• Any payment account which is accessible online is in scope.
• A PSU, via an AISP, should be able to access via an AISP, payment account and associated payment transaction information currently available to that PSU through the ASPSP online channel..
• This requires an extension to the existing Account and Transaction API (version 1) to cover these additional account types and additional data elements for each.

For Payment Initiation Services:

• Only payment accounts where a PSU can initiate payment via the ASPSPs online interface are in scope.
• A PSU, should be able to instruct the initiation of a payment order via a PISP from their online payment account.
• This requires an extension of the Payment Initiation API (version 1) to cover these additional account types, and also to extend this coverage to additional payment types (as applicable) Use cases

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

• As a customer, I want to use a tool to have a consolidated view of all my finances across multiple banks, loans, and credit card accounts, from multiple providers, so that I have an accurate view of my financial position helping me with my budgeting decisions.
• As a small business loan provider, I want to view transactional data from an applicant’s accounts across different financial instruments used by the applicant, so that I can have a more accurate view and apply my own criteria to assess whether I want to lend to them.
• As a customer, I want a consolidated view within my Personal Finance Management (PFM) tool of the pending balance transfers across my different credit cards with the expiry of the offer period for each, so that I can optimise the balance transfers to avoid higher interest rates.
• As a PFM provider, I want to alert customers when one of their balance transfer offer periods is about to expire, so that I can offer them a better deal through market comparison.

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

Notes on Payment Initiation Service:

• The above accounts marked Y above (in the PIS column) indicate that these accounts are in scope for the source account in the case where the ASPSP offers the ability for the PSU to make an online payment from these accounts.
• Purchase transaction from credit card accounts and charge card accounts are out of scope for PIS as they are not initiated by the PSU via the ASPSP’s online channels. 
• The destination for the payment must be reference-able via a sort code and account number.

Comments

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

• Money transfer from a card account to a bank account.
• B2B payments to an account using a virtual PAN.
• Payments to accounts via other references used by e-money accounts.

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:

• The consent model will not be impacted due to additional payment accounts in scope for V2.0.
• Some of the mandatory data elements currently available for version 1.1 release may not be applicable to some payment accounts
• The full dataset will be considered rather than a ‘most common denominator’ subset approach 

For Write APIs:

• The consent model will not be impacted due to additional payment accounts types in scope for V2.0.
• All Payment Types in the OB Roadmap will support payments from the payment accounts types listed above
• Referencing of the debtor account while using payment enabled saving, loan & mortgages will be using sort code and account numbers

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