Proposition P21 - PSD2 in-scope accounts (multi-currency)

1. Version Control

Version

Date

Authors

Comments

V0.1

 

OBIE API Delivery Team

Draft for information only

V0.2

 

OBIE API Delivery Team

For industry consultation & feedback including RLWG, PMG, PAG, SWFG, DWG

V0.3 OBIE API Delivery TeamUpdate based on consultation feedback for approval at IESG. See change log for details of all changes.
V1.0

 

OBIE API Delivery Team

Final version for approval at IESG

V1.1 OBIE API Delivery TeamUpdate based on Evaluation and Discovery workshop feedback and Errata. Formally document change.
V1.2 OBIE API Delivery TeamUpdate MoSCoW, Rationale and add Implementation for Detailed Product Requirements based on Categorisation of requirements for standards and implementation

2. Roadmap Item Definition

The original scope for Roadmap item “P21: PSD2 in-scope accounts (multi-currency)” was to extend the OB Read/Write APIs to support payer accounts of any currency.

Roadmap item “P20: PSD2 in-scope accounts (sterling)” was released as part of OB Read/Write APIs v2.0. This version supported referencing payer and payee accounts only using account number-sort code and IBAN. This limitation does not enable payments offered by ASPSPs within their online channel like balance/money transfers and payments to non-standard payment networks (e.g. Paym, PayPal). The ability for the APIs to support additional account identifiers was considered for future releases of P20.

P21 being an extension of P20, the requirement to extend the payer and payee account identifiers has been added to the original P21 scope.

The new P21 scope will 

  • enable multi-currency payment accounts for AISP/PISP/CBPII services, and 
  • extend the payer and payee account identifiers for PISP/CBPII services.

This paper defines the overall proposition to support this extended read/write functionality, so that participants (ASPSPs and TPPs) and stakeholders (FCA, HMT, CMA) have a common understanding about what is and is not in scope, and how this proposition will support regulatory requirements and key use cases.

Please refer to the Appendix (10.1 Roadmap item definition) for the original definition of “P21: PSD2 in-scope accounts (multi-currency)” within the "Notice of approval of changes to the Agreed Timetable and Project Plan"

3. Market Analysis

This section covers the current scale and the demand for the payments which will be supported by this proposition.

Multi-currency payments:

  • Multi currency accounts are offered by all major banks and Forex providers. 
  • The international payments in 2015 had an estimated volume of US$22 trillion with an approximate growth rate of 4.6% over the next five years.           
  • Most companies (90%) use banks to send payments internationally as compared to Consumers who are increasingly using nonbank FX providers or other means of payment (e.g. cards).

Detailed market analysis on international payments is covered under P10 International Payments: Market Analysis

Balance/Money Transfers

  • 17.3m credit and store cardholders in the UK have done a balance transfer.
  • 49% of balance transfers are not paid and one major reason being customers forgetting to switch at the end of promotional period.

(source: Zopa report of Credit cards )

TPP access to PSU balance transfer information and ability to initiate a balance transfer via a TPP, will enable tools that help customers better manage their credit.

P2P payments

  • P2P networks usually use a proxy (mobile number, email etc) for the payee account.
  • P2P payments were around $300 billion globally in 2017.
  • 50 P2P solutions currently co-exist in SEPA including Paym, PayPal, circle, venmo, Pingit, Google Wallet.
  • There are ASPSPs that support payments from their online channel to one or more of these payment networks (e.g. Paym).

(source: ERPB Working Group report on Person-to-Person Mobile Payments)

The Open Banking solution must enable TPPs and ASPSPs to be able to support such P2P payments.

4. Customer Use Cases

The following are some example use cases which were considered for this proposition:

IDP21:  multi-currencyMet

UC1: Personal finance Manager(PFM)

As a customer, I want to use a tool to have a consolidated view of all my finances across multiple providers and multiple currency accounts that I hold, so that I have an accurate view of my financial position helping me with my budgeting decisions.

Fully

UC2: SME payments

As a SME, I want to use my accountancy package to pay my overseas vendors directly using my multi currency accounts held with my bank.

Fully

IDP20: Extended payer and payee account identifiers
UC3: Credit account

As a customer, I want to pay for my online purchases using my credit account offered by my bank, so that I am aware of my credit limit, balance and charges which will be displayed by my bank before I confirm the payment.

(the credit account supports paying out to any account number and sort code)

Fully
UC4: Balance/Money transfers

As a customer, I want to use a Personal Finance Manager tool to initiate a Balance or Money transfer offered by one of the cards which I have previously added to the tool.

Prototypes:

Fully
UC5: P2P payments 

As a customer, I want to use a P2P app to pay someone from my bank account simply using their mobile number or email address.

Fully

UC6: E-commerce

As a customer, I want to use my debit card number(in place of account number/sort code) to initiate a payment from a retailer site and save this with the retailer to speed up my checkout process for future purchases.

Fully


5. Regulatory references

The OBIE interpretation of the key regulatory requirements is that in relation to payment accounts that are accessible online, the ASPSP  should allow same payment functionality via a PISP and make the same information available via an AISP, as available to the PSU on their online, payment account.  ASPSP should also be able to respond to CBPII requests linked to payment accounts accessible online.

For AISP/CBPII services this includes access to multi currency accounts and for PISP services this includes payments like balance transfers, money transfers, payments initiated using payee's account proxy (email, mobile number), international payments from any source currency to destination currency supported by the ASPSP.

The functionality available to a PSU directly may vary from account to account depending on the online functionality provided by the ASPSP to the PSU.

The regulatory references relevant to each detailed requirement listed in table 10.1 are mapped in the column P19 alignment column.

6. Evaluation criteria

Key evaluation criteria that OBIE have applied for this proposition (that respect the objectives of meeting regulatory requirements as well as being effective and proportionate).

  1. Does the proposition meet the use cases from a PSU and a TPP perspective (from both an outcome and risk point of view)?
  2. Is the proposition implementable at reasonable cost?
  3. Does the proposition comply with all relevant regulations?

7. Product requirements

In order to allow all ASPSPs to comply with the regulatory requirements and meet key customer use cases, the Read/Write APIs will need to support the following functionality:

P21: multi-currency payer accounts

  1. AISP access to PSU payment accounts of all currencies offered by the ASPSP to the PSU.
  2. Payment initiation through PISP from all currency accounts offered by the ASPSP to the PSU.
  3. CBPII access to PSU payment accounts, for confirmation of funds,  of all currencies offered by the ASPSP to the PSU.

P20: Extended payer and payee account identifiers

  1. Ability for PISP to specify, as part of the consent, payer and payee account identifiers other than UK account number/Sort code/IBAN.
  2. Ability for CBPII to specify, as part of the consent, payer account identifiers other than UK account number/Sort code/IBAN.

These P20 extended account identifiers will enable payment types like balance/money transfers and payments to non standard networks (e.g Paym) via the PISP.

8. Considerations

8.1 Constraints

  • Payment initiation from a non GBP account can be supported by a PISP only if the ASPSP offers this capability within their online channel.
  • Proxies(email, mobile number) used for payee accounts are not inter-operable between payment networks(Paym, PayPal, Google Pay).
  • Payment initiation via a PISP to a proxy or any other account identifier is possible only for the payment networks supported by the ASPSP within their online channel (e.g. mobile number via Paym but not mobile number via PayPal).

8.2 Dependencies

  • PISPs will need a mechanism to discover the non standard payment networks supported by individual ASPSPs (Paym, PayPal etc).
  • PISPs will need a mechanism to discover if a ASPSP supports payment types like balance and money transfers.
  • PISPs will need a mechanism to understand the status of payment initiations like balance and money transfers as these are not immediate payments.

8.3 Assumptions

  • To the extent TPPs and/or ASPSPs are engaged in activities that are regulated under the FCA’s consumer credit regime (pursuant to the Financial Services and Markets Act 2000) we assume that such parties are responsible for compliance with their own respective regulatory obligations.

9. Measuring Adoption

The following metrics will be required to measure adoption:

  • Number of PISPs/AISPs/CBPIIs accessing non sterling accounts.
  • Volume of transactions for payments initiated(PISP) or for information(AISP/CBPII) from non sterling accounts.
  • Number of PISPs/CBPIIs using non standard account identifiers.
  • Volume of PISP/CBPII consent requests using non standard account identifiers(balance and money transfers, payments to non standard network).



10. Appendix

10.1  Detailed Product Requirements

Requirements marked as 'M'(Must) and 'S'(Should) as per the MoSCoW ratings are in scope for delivering the minimum viable product. All other requirements are listed for future consideration.

Requirements marked as 'M'(Must) are in scope of the OBIE solution. All other requirements are listed for future consideration. The final column indicates whether each requirement is 'mandatory', 'conditional' or 'optional' for implementation by ASPSPs and/or TPPs. These terms are defined here: Categorisation of requirements for standards and implementation.

These are stated as requirements of the OBIE solution to enable implementers to meet regulatory compliance and/or customer use cases.

The requirements for P21 are dependent on the detailed requirements covered under following roadmap items:

10.1.1 P21 Multi-currency

IDDescriptionMoSCoWRationaleP19 alignmentImplementation
1

OBIE solution must allow a PISP to transmit or confirm the PSU's consent in respect to accounts of any currency in accordance to OBIE consent model.

M

Regulatory

 PSR8

Conditional

(Mandatory if provided by ASPSP on existing channel)

2

The OBIE's Solution(s) must enable PISPs to initiate payer-initiated payment transactions from payment accounts of any currency provided the PSU can initiate a payment from these accounts within the ASPSPs online channel.

These payment initiations include

M

Regulatory PSR2PSR3

Conditional

(Mandatory if provided by ASPSP on existing channel)

3The OBIE's Solution(s) must allow a AISP to transmit or confirm the PSU's consent in respect to accounts of any currency in accordance to OBIE consent model.MCustomer

Conditional

(Mandatory if provided by ASPSP on existing channel)

4The OBIE's Solution(s) must allow a CBPII to transmit or confirm the PSU's consent in respect to accounts of any currency in accordance to OBIE consent model prior to receipt of the first request for confirmation of funds from that CBPII.MCustomer

Conditional

(Mandatory if provided by ASPSP on existing channel)

4The OBIE's Solution(s) must enable AISPs access to PSU payment accounts of any currency provided the PSU can access these accounts through the ASPSPs online channel.MRegulatoryPSR1

Conditional

(Mandatory if provided by ASPSP on existing channel)

5

The OBIE's Solution(s) must enable CBPIIs to request a confirmation of funds from a payment account of any currency provided the PSU can access this account through the ASPSPs online channel.

The currencies supported in the CBPII request and all other requirements around the confirmation of funds are covered under P6: Confirmation of funds

MRegulatoryPSR9

Conditional

(Mandatory if provided by ASPSP on existing channel)

10.1.2 P20 Extended payer and payee account identifiersSpace

ID

Description

MoSCoWRationaleP19 alignmentImplementation
PISP
1

The OBIE's Solution(s) must enable the PSU to provide the PISP, a valid identifier that can reference the payment account with the ASPSP.

(complete list of account identifiers is listed in 10.1.1 Payer account identifiers)

MCustomer


Mandatory

(Needed for the API to work)

2

The OBIE's Solution(s) must allow ASPSPs to reject a PISP request if the PSU uses an invalid identifier with the PISP to reference the payment account ( e.g. expired/reported lost stolen primary/secondary PAN).

MCustomer

Conditional

(Mandatory if provided by ASPSP on existing channel)

3

The OBIE's Solution(s) must enable ASPSPs to navigate the PSU directly to the authorisation step after successful PSU authentication during a payment initiation, if the PSU uses a valid identifier for the payer account with the PISP.

PSU must not be required to make further selections of product type (Personal/Business/Credit cards) or accounts within a product with the ASPSP.

MCustomer

Refer to Customer Experience Guidelines

4The OBIE's Solution(s) must allow ASPSPs to execute, on the scheduled date(s), payment(s) within a future dated payment order(SO,FDP) which was setup via a PISP, even if the identifier used by the PSU may no longer be valid (e.g. expired/reported lost stolen PAN).MCustomer

Refer to Customer Experience Guidelines

5

The OBIE's Solution(s) must enable the PISP to specify any of the valid identifiers for a payee account provided the ASPSP supports these identifiers for a payee account within their online channel. 

(complete list of payee account identifiers is listed in 10.1.2 Payee account identifiers)

MRegulatory

RTS15,

RTS 26

Conditional

(Mandatory if provided by ASPSP on existing channel)

6

The OBIE's Solution(s) must enable the PISP to specify the payment network,  provided the ASPSP supports that payment network within their online channel  (e.g. Paym, BACS, FPS)

1 and 5,6 will enable balance/money transfer and payments to non standard networks (e.g Paym) via the PISP.

(list of payment networks is listed in 10.1.3 Payment networks)

MCustomer

Conditional

(Mandatory if provided by ASPSP on existing channel)

7

The OBIE's Solution(s) must enable a ASPSP to resolve payee from  the identifier provided by the PSU after the PSU is authenticated (provided the ASPSP supports the functionality currently).

e.g If PISP initiates a payment to a Paym registered mobile number then the ASPSP should be able to resolve the name of the payee with the ASPSP after the PSU authenticates with the ASPSP

MCustomer

Refer to Customer Experience Guidelines

8

The OBIE's Solution(s) must allow ASPSPs to publish the following information related to payment accounts offered by them in a standard format

MCustomer

Conditional

(Mandatory for TPPs to know what is supported by ASPSP)

9

The OBIE's Solution(s) must allow the ASPSP to return the status of the payment initiation to the PISP immediately after the receipt of a balance/money transfers and payments to non standard networks.

MRegulatory

PSR12

Mandatory

(Get on status endpoint is mandatory in Specs v3.0)

10

The OBIE's Solution(s) must enable the PISP to return the payment amount and charges applied by the PISP (with breakdown where applicable) immediately after the receipt of the payment order.

MRegulatoryPSR4

Mandatory

(PSD2 requirement for Guidelines for PISP to provide this to PSU)

11

The OBIE's Solution(s) must enable ASPSPs to provide information, before the PSU authorises a payment order initiated via a PISP,  on the applicable execution time, charges (with breakdown) and any other specific applicable terms.

MCustomer

Optional

(There is no specific regulatory requirement for this)

12

The OBIE's Solution(s) must enable ASPSPs to provide information to the PSU (via PSU's PISP) on the applicable execution time and charges (with breakdown)  for a payment order initiated via a PISP.

MCustomer
Mandatory
13

The OBIE's Solution(s) must enable, from the ASPSP online channel, revocation of a balance/money transfer or payment to a non standard network initiated via a PISP, provided this functionality is offered by the ASPSP when these payments  are setup directly with the ASPSP.

MCustomer

Optional

(This functionality sits within the ASPSP space and does not require an OBIE Solution)

14

The OBIE's Solution(s) could allow the ASPSP to return the status of payment execution to the PISP which can happen at any further time after the receipt of a balance/money transfer or payment to a non standard network.

This is being evaluated as part of P9 - Status of payment

CCustomer

Future Consideration

(To be covered under P9)

15

The OBIE's Solution(s) could allow the PSU to revoke a balance/money transfer or payment to a non standard network, via the PISP through which it was was initiated, provided this functionality is offered by the ASPSP when these payments  are setup directly with the ASPSP.

CCustomer

Future Consideration

(There is no regulatory requirement nor any immediate propositional need for this capability)

CBPII
16

The OBIE's Solution(s) must enable the PSU to provide the CBPII, a valid identifier that can reference the payment account with the ASPSP.

(complete list of account identifiers is listed in 10.1.1 Payer account identifiers)

MCustomer 

Conditional

(Mandatory if provided by ASPSP in existing channel)

17

The OBIE's Solution(s) must allow ASPSPs to reject a CBPII consent request if the PSU uses an invalid identifier with the CBPII to reference the payment account ( e.g. expired/reported lost stolen primary/secondary PAN).

M


Customer

Mandatory

(Mandatory if provided by ASPSP in existing channel)

18

The OBIE's Solution(s) must allow a CBPII request for confirmation of funds even if the identifier, used by the PSU with the CBPII as part of the original consent , is no longer valid where that identifier is not an account number and/or sort code( e.g. expired/reported lost stolen primary/secondary PAN).

M

Customer


Optional

19

The OBIE's Solution(s) must enable ASPSPs to navigate the PSU, after successful PSU authentication , directly to the consent authorisation for confirmation of funds , if the PSU uses a valid identifier for the payer account with the CBPII.

PSU must not be required to make further selections of product type (Personal/Business/Credit cards) or accounts within a product with the ASPSP

M

Customer


Refer to Customer Experience Guidelines


Identifiers which can be used with the PISP/CBPII request to reference Payer’s account 

Payer payment account type

Valid identifiers used with PISP/CBPII

(as supported by individual ASPSP)

PCA

BCA

Payments enabled flexible savings accounts

Payments enabled deposit accounts

Payments enabled loan accounts

Payments enabled mortgage accounts


Account Number – Sort code

Account Number – Sort code / Roll Number

IBAN

PAN (All valid PANs associated with the account)

Credit Card

Charge Card

PAN ( All valid PANs )

Account Number – Sort code

e-money accounts

Account Number – Sort code

IBAN

PAN (eg. All valid PANs associated with the account)

Alphanumeric ID ( email, mobile, any non standard ID)

details of permissible character sets to be covered in the design phase


Identifiers which can be used with the PISP request to reference Payee's account 

Payee payment account Type

Valid identifiers for payee account used with PISP

(as supported by individual ASPSP)

PCA

BCA

Payments enabled flexible savings accounts

Payments enabled deposit accounts

Payments enabled loan accounts

Payments enabled mortgage accounts


Account Number – Sort code

Account Number – Sort code/ Roll Number

IBAN

PAN (All valid PANs associated with the account)

Credit Card

Charge Card

PAN (All valid PANs associated with the account)

Account Number – Sort code

e-money accounts

Account Number – Sort code

PAN(All valid PANs associated with the account)

Alphanumeric ID ( email, mobile, any non standard ID)

details of permissible character sets to be covered in the design phase


This list is not exhaustive and will be updated as ASPSPs support more payment networks from their online channel

Payment network

Valid identifiers for payee account

(as supported by individual ASPSP)

BACS,CHAPS,FPS

Account number-Sort Code

Account number-Sort Code + Roll number 

SWIFT,SEPA

For example

  • Australian account number and BSB code
  • British account number and sort code
  • IBAN
  • US account number and routing number

Details under Proposition P10 - International Payments 

Link

PAN

Paym

Alphanumeric ID

details of permissible character sets to be covered in the design phase

Pingit

Mobile number

PayPal

mobile number, username, ID

Google P2P payments

Email address

circle

Email, mobile  number

10.2 Roadmap item 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)

Description

Rationale

Aligns with

Scope Item description:

Extension of OB R/W APIs to cover the full set of PSD2 multi-currency products not covered under the Order (including but not limited to currency cards, 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 product and functionality referred to above (and leveraging the learning from the development of international payments standards in item P10 of the Amended Order Timetable) 

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 the Order by aligning with PSD2

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 foreign currency 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