P6 • Confirmation of funds

1. Version control

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:

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.

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)

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.

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.