Proposition P6 - Confirmation of funds

1. Version control

Version

Date

Authors

Comments

V0.1

 

OBIE API Delivery Team

Draft for internal review

V0.2

 

OBIE API Delivery Team

For review RLWG, PMG, PAG, SWFG, DWG

V0.3

 

OBIE API Delivery Team

Update based on consultation feedback for approval at IESG. See change log for details of all changes.

V1.0

 

OBIE API Delivery Team

Final version, approved at IESG on  (no changes from v0.3).

V1.1 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 Open Banking API's v1.1 covered single immediate payments (Write functionality) where a PSU can initiate, through a PISP, a one off payment to be initiated immediately from their PCA/BCA account held with an ASPSP.

From a regulatory compliance perspective the Open Banking APIs need to be extended to enable ASPSPs to confirm availability of funds to a special group of TPPs; a new entity called Card Based Payment Instrument Issuers (CBPIIs). CBPIIs are payment service providers which issue card based instruments which are linked to an account or accounts held at one or more different ASPSPs.

This paper defines the overall proposition to support this extended API 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.

For actual roadmap item definition and other related definitions please refer to sections 10.3 and 10.4 of the Appendix.

3. Market analysis

Whilst today, most payments at the point of sale are card based, the current degree of innovation in the field of payments might lead to the rapid emergence of new payment channels in the forthcoming years. The European Commission believes that the issuing of card-based payment instruments by PSPs, whether credit institutions or payment institutions, other than the ones servicing the accounts of customers, would provide increased competition in the market and thus more choice and a better offer for consumers. (PSD2, c 67).

PSPs issuing card-based payment instruments should enjoy the same rights and should be subject to the same obligations under PSD2, regardless of whether or not they are the ASPSP of the payer (PSD2, c 68). For PSPs issuing card based payment instrument, particularly debit cards, obtaining confirmation of availability of funds on the customer's account from the ASPSP would enable the issuer to better manage and reduce its credit risk. At the same time, that confirmation should not allow the ASPSP to block funds on the payer's payment account. (PSD2, c 67).

The use of a card or card-based payment instrument for making a payment often triggers the generation of a message confirming availability of funds and two resulting payment transactions. The first transaction takes place between the issuer and the merchant's ASPSP, while the second, usually a direct debit, takes place between the payer's ASPSP and the issuer.

Currently, credit institutions remain the principal gateway for consumers to obtain payment instruments. In the UK, there are currently no known to OBIE Card Based Payment Instrument Issuers (CBPIIs), whether credit or payment institutions, neither any known companies aspiring to become CBPIIs under the PSD2 definition.

4. Customer use cases

The following is the key/high priority use case for roadmap item P6:

ID

Use Case

Met

UC1 – CoF for CBPII linked account

As a customer using a card from a CBPII issuer linked to my payment account of another provider,
I want to allow the CBPII card issuer to confirm availability of funds in my linked account the execution of my card transaction, so that I can benefit from multiple CBPII card offerings and increased competition in the market.

Fully

UC2 – CoF for PISP

As a customer of a merchant using a PISP,
I want to merchant to confirm my payment and process my order in advance of the PISP having a confirmation that they payment initiation has been successful.
Note: This use case in not in scope for the roadmap item P6

Not at all

There was no PSU testing performed on the CoF proposition journeys. The expected high level user journeys for CBPIIs can be found in section 10.5.2 of the Appendix, and the prototype in section 10.7.

5. Regulatory references

Under the PSRs, Regulation 68, a payment service provider (PSP) can issue a card based instrument which is linked to an account or accounts held at one or more different ASPSPs provided the account is accessible online. The payment service provider that issues the payment instrument is known as a Card-Based Payment Instrument Issuer or CBPII.

When the PSU uses the card-based payment instrument to initiate a card transaction, the CBPII is entitled to request a confirmation from the PSU's ASPSP to which the account is linked to, to confirm whether there are sufficient funds available for the card transaction. The ASPSP is obliged to respond with a 'yes/no' answer immediately provided the relevant regulatory requirements are met.

Under the RTS, the key requirement is that the CBPII must identify itself to the ASPSP and they can use the dedicated interface of the ASPSP to do this. This also means that they will be entitled to use the testing facility.

Other Key Points:

  • The initiation of the payment is card based. However, the settlement from the payer's ASPSP account to the CBPII could use any payment scheme or method, including Open Banking (if CBPII is also a PISP).
  • The Confirmation of Funds Response must not be stored by CBPII.
  • Confirmation received by the CBPII cannot be used for any other purpose than the execution of the card based payment for which the request is made.
  • The Confirmation of Funds must be uniquely referenced
  • The ASPSP must have the explicit consent of the PSU prior to responding to the CBPII. This is related to each specific CBPII.
  • The ASPSP is not permitted to provide additional account information (such as the account balance) or block funds on the PSU's account for the card payment transaction. 
  • Upon request of the payer, the ASPSP must inform the payer of the identity of CBPII which made the CoF request and its response.

5.1 Other considerations

  • CBPII does not necessarily need to be an Open Banking PISP in order to use the Confirmation of Funds functionality of the ASPSP. There is thus a requirement for OBIE to recognise a separate CBPII legal entity. A CBPII is expected to be a legal entity with a separate FCA license.
  • There is no regulatory requirement that requires the ASPSP to provide a CoF Response to a request generated by a PISP for non-card based transactions. Furthermore, PSD2 regulations do not allow PISPs to make CoF requests to ASPSPs as part of the PISP journey. This activity is not part of the standard Payment Initiation service definition.
  • It is also identified that an AISP should not have access to the CoF API endpoint, as a) this would be an extension to AISP capability, b) there would not be a clear use case for an AISP, and c) in any case, the AISP would have access to PSU's available balance (which would negate the need for this functionality).

For detailed Regulatory references, please refer to section 10.2 of the Appendix.

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)

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

7. Product requirements

OBIE understands that the CoF API may need to support the following functionality:

  • Open Banking system support for the new CBPII entities i.e. they should be able to identify themselves to the ASPSP.
  • PSU explicit consent to CBPII and explicit consent to ASPSP for CoF Requests on selected accounts linked to CBPII card.
  • CoF Request generation from CBPII to ASPSP for a specific amount related to a CBPII card transaction is available and respond with a Y/N answer.
  • PSU ability to revoke their consent.
  • Upon request to the ASPSP, PSU ability to be informed of  information of a specific CoF Request by a specific CBPII and the answer provided by ASPSP.
  • CoF support for all accounts defined in item P20.
  • CoF support for multi-currency and multi authorisation accounts.

The following are not considered to be regulatory requirements for this specific proposition:

  • Extension of the CoF functionality mentioned above to support PISPs.
  • Extension of this new endpoint for AISPs.

For detailed list of Product Requirements, please refer to section 10.1 of the Appendix.

8. Considerations

8.1 Constraints

The FCA Approach Document confirms that ASPSPs are not obliged to respond to requests from CBPIIs before the strong customer authentication regulatory technical standards apply (Please refer to Regulatory references FCA Section 7.6)

8.2 Dependencies

  1. There is dependency on having an onboarding policy of CBPIIs for both the FCA (and/or other NCAs) and the Open Banking Directory for the specific role of CBPII
  2. There is dependency on roadmap item P13 for the support of CoF functionality for multi-authorisation accounts
  3. There is dependency on roadmap item P21 for the support of CoF functionality for multi-currency accounts (non GBP accounts)

8.3 Assumptions

  1. CBPII entities will be supported by FCA and Open Banking.
  2. CBPIIs must have the PSU's CBPII card linked directly to an account at different ASPSP , which is accessible to make CoF Requests.
  3. CoF API is a standalone API.
  4. There is no overlap with roadmap item P10, as if the card of the CBPII was used in an international payment where FX was involved, the FX conversion would be managed by the CBPII and the CoF amount should only be in the currency of the authorised for CoF account.
  5. Currently, CoF will not be supported for multi-authorisation accounts, as this will be managed under roadmap item P13.
  6. The account identification fields used for CoF consent will be the ones defined under roadmap item P20. Currently, customers are able to use sort code/account number for identification. However, further additions may take place in the future (e.g. the use of debit card PAN for account identification).
  7. Participants should define information requirements, for example AML and counter fraud or information security data requirements to be included as part of the API specification relevant to each proposition.
  8. A fair use policy could apply, however there will be challenges to know the PSU behaviour to apply fair usage policy fairly. This will be investigated further during the design phase.

9. Adoption Metrics

The following metrics will be required to measure the adoption of the CoF proposition:

  1. Number of CBPIIs entities utilising the CoF API end point
  2. Number of customer authorisations for CoF to CBPIIs
  3. Daily volumes of CoF requests per CBPII per ASPSP
  4. Number of CoF status and history requested by PSUs

10. Appendix

10.1 Detailed product requirements

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

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.

ID

Requirement

MoSCoW

Rationale

Use Cases

Implementation

1

The OBIE's Solution(s) must allow PSPs offering CBPII, to identify themselves to the ASPSPs

M

Regulatory 

UC1

Mandatory

(If endpoint is implemented by ASPSP

2

The OBIE's Solution(s) must enable the payer to provide the ASPSP with explicit consent to provide a confirmation of funds response to a CBPII, prior to receipt of the first response from that CBPII

For example:

  1. PSU gives explicit consent for CBPII A to their ASPSP prior receipt of first request
  2. CBPII receives explicit consent from PSU to request a ‘yes’ or ‘no' answer
  3. CBPII submits the request when the payment instrument is used.
  4. The ASPSP provides the CBPII with a ‘yes’ or ‘no’ answer


M

Regulatory 

UC1

Mandatory

(Required as per Article 65 of PSD2)

3

The OBIE's solution(s) must enable an on-going/long-lived consent which may have an expiry date.

M

Customer 

UC1

Mandatory

(PSD2 does not specify a maximum length of consent (it can persist indefinitely), however TPPs may agree a specific expiry date with their PSUs.)

4

OBIE's Solution(s) for confirmation of funds must enable CBPII to send a CBPII requests for all types of online, payment accounts.

For detailed info of P20 accounts in scope, please refer to section 10.6 of the Appendix (excludes card based instruments on which e-money is stored).

M

Regulatory 

UC1

Conditional

(Mandatory if provided by ASPSP in existing channel)

6

OBIE's Solution(s) must require TPPs to include unambiguous references to PSU, transaction and CoF request as applicable in all communications with ASPSP

M

Regulatory 

UC1

Mandatory

(If endpoint is implemented by ASPSP)

7

The OBIE's Solution(s) must not define any limit as to how many calls can be made against this consent in any given time period.

M

Customer

UC1

Refer to Customer Experience Guidelines

8

The OBIE's Solution(s) must support an immediate Yes/No response to an availability of funds confirmation request for CBPIIs.

Notes:

  • A ‘yes’ response from an ASPSP does not guarantee that a subsequent settlement payment will be successful.
  • There is not necessarily a 1:1 relationship of CoF requests and settlement payments. For example, a CBPII could issue multiple CoF requests and settle with a single payment.

M

Regulatory 

UC1

Mandatory

(If endpoint is implemented by ASPSP)

11

The OBIE's Solution(s) must provide the ability for the PSU to revoke explicit consent through the ASPSP.

M

Customer 

UC1

Refer to Customer Experience Guidelines

12

The OBIE's Solution(s) must provide the the ability for the PSU to revoke their explicit consent through the CBPII.

M

Customer 

UC1

Mandatory

(Delete endpoint is mandatory for ASPSP to implement)

13

The OBIE's Solution(s) must enable the ability for the ASPSP to provide (upon request from the PSU), information of a specific CoF Request by a specific CBPII and the answer provided by ASPSP.

M

Regulatory

UC1

Refer to Customer Experience Guidelines

(Required by PSR,Reg.68(6))

14

The OBIE's Solution(s) must enable the ability to view (upon request from the PSU) the CoF Request and Response history per each CBPII on the ASPSP dashboard.

M

Customer

UC1

Refer to Customer Experience Guidelines

15

The OBIE's Solution(s) must enable the CoF functionality for supported non-GBP currency accounts (see roadmap item P21).

M

Regulatory

UC1

Conditional

(Mandatory if provided by ASPSP in existing channel)

16

The OBIE's Solution(s) must enable the CoF functionality for supported accounts where multiple authorisations are required (see roadmap item P13).

M

Regulatory

UC1

Conditional

(Mandatory if provided by ASPSP in existing channel)

17

The OBIE's Solution(s) won't extend the CoF functionality to support PISPs.

M

Regulatory


Future Consideration

(Was not considered a regulatory requirement initially)

18

The OBIE's Solution(s) won't extend the provision of CoF functionality to payment transactions initiated through card-based payment instruments on which electronic money is stored.

M

Regulatory


Future Consideration

(Was not considered a regulatory requirement initially)

19

The OBIE's Solution won't extend the CoF functionality to new endpoint for AISPs.

C

Customer


Future Consideration

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

20

The OBIE's Solution won't extend the CoF functionality to Corporate accounts (see item P22).

M

Regulatory


Future Consideration

(Was not considered a regulatory requirement initially)

21The OBIE's Solution(s) must allow a CBPII to request a confirmation of funds available from the holder of the payer's payment accountMRegulatoryUC1

Mandatory

(If endpoint is implemented by ASPSP)

10.2 Regulatory References

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

  • PSR, Regulation 68 (Confirmation of availability of funds for card based payment transactions) referring to PSD2 Article 65 states:

1.This regulation does not apply to payment transactions initiated through card-based payment instruments on which electronic money is stored.
2.Where the conditions in paragraph (3) are met, a payment service provider which issues card-based payment instruments may request that an account servicing payment service provider confirm whether an amount necessary for the execution of a card-based payment transaction is available on the payment account of the payer.
3.The conditions are that:

  1. the payer has given explicit consent to the payment service provider to request the confirmation;
  2. the payer has initiated a payment transaction for the amount in question using a card-based payment instrument issued by the payment service provider making the request;
  3. the payment service provider making the request complies, for each request, with the authentication and secure communication requirements set out in [the Regulatory Technical Standards developed by the EBA] in its communications with the account servicing payment service provider.
  4. If the conditions in paragraph (5) are met, an account servicing payment service provider which receives a request under paragraph (1) must provide the requested confirmation, in the form of a 'yes' or 'no' answer, to the requesting payment service provider immediately.

5.The conditions are that:

  1. the payment account is accessible online when the account servicing payment service provider receives the request; and
  2. before the account servicing payment service provider receives the first request under paragraph (1) from the requesting payment service provider in relation to the payer's payment account, the payer has given the account servicing payment service provider explicit consent to provide confirmation in response to such requests by that payment service provider.

6.If the payer so requests, the account servicing payment service provider must also inform the payer of the payment service provider which made the request under paragraph (1) and the answer provided under paragraph (3).
7.An account servicing payment service provider must not:

  1. include with a confirmation provided under paragraph (3) a statement of the account balance; or
  2. block funds on a payer's payment account as a result of a request under paragraph (1).

8.The payment service provider which makes a request under paragraph (1) must not:

  1. store any confirmation received under paragraph (3); or
  2. use the confirmation received for a purpose other than the execution of the card-based payment transaction for which the request was made.
  • FCA Approach Document

8.159 Under regulation 68 of the PSRs 2017, CBPIIs can request confirmation from an ASPSP whether a customer has funds available in its payment account to complete a transaction at a given point in time. Regulation 68 of the PSRs 2017, however, only governs the confirmation process (i.e. where the ASPSP confirms whether funds are available). It does not govern subsequent settlement of the transaction between the payee, CBPII and the payer, which may vary between different business models.


  • HMT 5.8 (3) states:

Availability of funds: Under Article 65, a PSP issuing card-based payment instruments, which does not hold the customer's payment account, is entitled to obtain confirmation of availability of funds on a payer's account from the ASPSP, subject to a customer's explicit consent and conditions being met. Confirmation does not allow the ASPSP to block funds on the payer's payment account.

  • RTS Article 35 Security of communication session states:

Account information service providers, payment initiation service providers and payment service providers issuing card-based payment instruments with the account servicing payment service provider shall contain unambiguous references to each of the following items:
(c) for confirmation on the availability of funds, the uniquely identified request related to the amount necessary for the execution of the card-based payment transaction.

  • FCA Section 17.20 (Payment Services and Electronic Money –Our Approach - The FCA's role under the Payment Services Regulations 2017 and the Electronic Money Regulations 2011) states:

Communication with CBPIIs, PISPs and AISPs (regulations 68(3)(c) 69(2)(a) and 70(2)(a))
17.20 Regulations 68(3)(c) 69(2)(a) and 70(2)(a) of the PSRs 2017 apply 18 months after the SCA-RTS is published in the Official Journal of the European Union. At this point, an ASPSP must communicate with CBPIIs, PISPs and AISPs (including with their agents or outsourcers where providing relevant aspects of their service) in accordance with the SCA-RTS. In summary, the SCA-RTS will require ASPSPs to communicate securely and to offer a method of access to AISPs, PISPs and CBPIIs which complies with a number of minimum standards. Where an ASPSP provides multiple secure methods of access, at least one of those methods of access must meet all of the ASPSP's obligations under the PSRs 2017 (including the SCA-RTS when it becomes applicable).

  • FCA Section 7.3 states (Implementation of the revised Payment Services Directive (PSD2): Approach Document and final Handbook changes – PS17/19 – September 2017) states:

The PSRs 2017 (reflecting PSD2) also sets out requirements for the confirmation of availability of funds for card-based payment transactions involving CBPIIs. These are PIs that issue payment instruments that are linked to an account held with a different ASPSP. These firms can get confirmation that funds are available on the account held with the ASPSP, enabling CBPIIs to manage their credit risk.

  • FCA Section 7.6 (Implementation of the revised Payment Services Directive (PSD2): Approach Document and final Handbook changes – PS17/19 – September 2017) states:

Intermediate period before the SCA RTS applies: We also do not change our guidance to note that ASPSPs are not obliged to respond to requests from CBPIIs to confirm that funds are available before the SCA RTS applies. We believe that this situation is unlikely to arise given that there are no mechanisms available at present for firms to use for this purpose, and there is no obligation on ASPSPs to create an interface to allow this communication until the SCA RTS applies.

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

P6 - Confirmation of Funds (CoF)

Description

Rationale

Aligns with

Scope Item description:

  • Extension of write (PIS) functionality of the OB R/W APIs to enable ASPSPs to confirm availability of funds to TPPs

    Key activities:
  • A discovery phase by the OBIE to understand gaps in existing functionality and create the business requirements for the standards
  • The development of standards by the OBIE for the products and functionality referred to above
  • The implementation of those standards by the CMA9 for Release

Regulatory alignment:

  • Supports provision of 3rd party services envisaged in the Retail Banking Market Investigation
  • Fulfils the requirements of the Order by aligning with PSD2

    Open Banking adoption:
  • Extends functionality of OB Standards for payments use cases and thereby delivers greater utility for TPPs

    Consumer / SME utility:
  • Consumers would be able to execute payments with confidence
  • Security / Integrity:
  • Consumers would be able to execute payments conveniently without putting cards on file

CM9 Order

10.4 Definitions

In the context of roadmap item P6, the follow definitions apply:

  • Confirmation of Funds (CoF) Request: The action from a PSP (which issues card-based payment instruments) of requesting from an ASPSP to confirm whether an amount necessary for the execution of a card-based payment transaction is available on the payment account of the payer. For the request to take place, the following must be met:
  • the payer has given explicit consent to the PSP to request the confirmation
  • the payer has initiated a payment transaction for the amount in question using a card based payment instrument issued by the PSP making the request
  • the PSP making the request complies, for each request, with the authentication and secure communication requirements set out in Article 98 of PSD2
  • Confirmation of Funds (CoF) Response: The action from an ASPSP (after receiving a Confirmation of Funds Request) of providing the requested confirmation, in the form of a 'yes' or 'no' answer, to the requesting PSP immediately. For the response to take place, the following must be met:
  • the payment account is accessible online when the ASPSP receives the request
  • the payer has given the ASPSP explicit consent to provide confirmation in response to such requests by that PSP, before the ASPSP receives the first request from the requesting PSP
  • In addition, if the payer so requests, the ASPSP must also inform the payer of the PSP which made the CoF request and the answer provided to the PSP.

10.5 User journeys for Cards and CBPIIs

10.5.1 Existing Card Payments Process

Traditional card scheme based payment

  • The customer provides their card details to the merchant.
  • The payment request then goes to the merchant's acquiring bank and then to the relevant card scheme (e.g. VISA, MasterCard) for authorization.
  • Once the validation is successful, a request for the payment is sent to the customer's card issuing bank where verification is done and the payment is issued

10.5.2 Card Payment Process under PSD2

Payments networks primarily operate under two different business models that can apply to CBPII.

  1. Open-loop payments networks, such as Visa and MasterCard that are multi-party and operate through a scheme that connects two financial institutions.
  2. Closed-loop networks which issue cards directly to consumers and serve merchants directly.

Any authorised PSP, be it a bank or a payment institution, can issue payment instruments. Payment instruments do not only cover payment cards, such as debit cards and credit cards, but any personalised device or set of rules agreed between the issuer and the user used to initiate a payment.

Card Based Payment Instrument Issuer (CBPII) - Open Loop Example

Setup Process

Usage during Transaction

Card Based Payment Instrument Issuer (CBPII) - Closed Loop Example

Setup Process

Usage during Transaction


10.6 P20 Accounts in scope (current view)

Caveat: The below table is the current view of the P20 roadmap item and is subject to change due to future CRs.

Account Type

Description

Current accounts

Personal and business current accounts

Payments enabled flexible savings accounts

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

Payments enabled deposit accounts

Deposit accounts which allow initiation of payments from an online channel of the ASPSP

Payments enabled loan accounts

Loan accounts which allow initiation of payments from an online channel of the ASPSP

Payments enabled mortgage accounts

Current 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

e-money accounts

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

Credit card accounts

Credit 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

Charge card accounts

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

10.7 Prototype

A prototype has been developed to demonstrate the customer journey when setting up and providing consent to a CBPII and explicit consent to the ASPSP during CoF setup.

This prototype will be shared with the final version of this paper.