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

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)

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:

• PFM, AISP view of Credit Card accounts: https://invis.io/ZXHD8G1B95V
• PFM, Balance Transfer initiation: https://invis.io/VJHD8JJSHR6

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.

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

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.

Regulatory

Conditional

(Mandatory if provided by ASPSP on existing channel)

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

• Single immediate payments(SIP), covered under OB R/W API v2.0
• Setup of SO or FDP, covered under  P5(a): Future dated payments and standing orders
• Payments in cross currencies, covered under Proposition P10 - International Payments
• Payments in same currencies but cross border, covered under Proposition P10 - International Payments ( Forex requirements do not apply)

M

Conditional

(Mandatory if provided by ASPSP on existing channel)

Conditional

(Mandatory if provided by ASPSP on existing channel)

Conditional

(Mandatory if provided by ASPSP on existing channel)

Conditional

(Mandatory if provided by ASPSP on existing channel)

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

Conditional

(Mandatory if provided by ASPSP on existing channel)

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)

Mandatory

(Needed for the API to work)

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

Conditional

(Mandatory if provided by ASPSP on existing channel)

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.

Refer to Customer Experience Guidelines

Refer to Customer Experience Guidelines

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)

RTS15,

RTS 26

Conditional

(Mandatory if provided by ASPSP on existing channel)

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)

Conditional

(Mandatory if provided by ASPSP on existing channel)

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

Refer to Customer Experience Guidelines

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

• Payment identifiers supported for the payer and the payee accounts( Table 10.1.2 Payee account identifiers, 10.1.3 Payment networks).
• Payment networks supported (e.g. Pay, PayPal,BACS, Table 10.1.3 Payment networks).
• Payment types supported (e.g. balance transfers, money transfers, SIP, FDP, SO).

Conditional

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

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.

PSR12

Mandatory

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

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.

Mandatory

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

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.

Optional

(There is no specific regulatory requirement for this)

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.

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.

Optional

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

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)

Conditional

(Mandatory if provided by ASPSP in existing channel)

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

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

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

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

Account number-Sort Code

Account number-Sort Code + Roll number 

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

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

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