P6b • Confirmation of Funds – PISP

1. Version control

2. Overview

The current published Version 3.0 of the OBIE read/write API standard includes functionality to allow a CBPII to receive a ‘yes/no’ response to a Confirmation of Funds (CoF) request. However, this functionality is not currently available to a PISP. This functionality is required by PISPs to assist them to reduce settlement risks, particularly in the case where there is no (near) real-time payment execution (e.g. Faster Payments).

In its Opinion paper published on 13 June 2018, the EBA clarified that Art. 36(1)(c) of the RTS applies to PSPs including CBPIIs and PISPs, rather than solely CBPIIs.^[1]  This means that ‘yes/no’ confirmation of funds functionality must be made available to PISPs. ASPSP to be able to respond with either a ‘yes’ or ‘no’ or provide supplementary information to the PISP to make its own judgement.

This paper is to document product requirements to address and support the Confirmation of Funds (CoF) functionality for PISPs.

3. Regulatory Assumptions

1. A PISP may only access, use or store the ‘yes/no’ confirmation where this information is for the provision of a payment initiation service explicitly requested by the payer.^[2]
2. If requested by the PISP, the ASPSP must provide an immediate ‘yes/no’ confirmation of whether the amount necessary for the execution of a payment transaction is available.^[3] The ASPSP should take into account the same information (eg available balance, agreed overdraft, incoming and outgoing funds, any fees and charges) it would consider if the customer was executing a payment transaction directly with the ASPSP.^[4]
3. The PISP can request the confirmation of funds for payments where the debit is real time or for delayed booking (executed not later than next working day).^[5]
4. Where a no response is received, it is up to the PISP to display a relevant message back to the PSU.
5. In contrast to the situation in which a CBPII is requesting confirmation of funds, a PISP does not need to obtain explicit consent from the PSU to make the request,^[6]nor does the PSU need to provide explicit consent to its ASPSP prior to the first request being made.^[7] Accordingly, there is also no applicable concept of persistent consent or authority that may need to be refreshed.There are two types of ‘explicit consent’ that a PISP must obtain under the PSRs:
   • ‘Explicit consent’ for performance of a payment initiation service including the requesting of any information required for performance of that payment initiation service^[2] and
   • ‘Explicit consent’ for processing of personal data for performance of that payment initiation service^[10] .
6. The provision of information related to the available balance of an account is personal data. Therefore GDPR requires that both the PISP and ASPSP will need to be able to find a legal basis for processing this data which in the domain of the PISP is in the competitive space (but will most likely be contract) while the ASPSP can rely on the requirement to comply with Art 36(1)(c)^[3] of the RTS. The use of ‘yes’ and ‘no’ in the RTS is a clear indication of the application of the data minimisation principle.^[8]
7. The confirmation of funds request does not involve a payer accessing their account, nor is it an action that may imply a risk of payment fraud or other abuse.^[9] Accordingly, an additional application of SCA (beyond that which will be performed when the payment is initiated) is not required.

^[5] Our assumption is that the yes/no response is limited up to the point of initiation of the payment order and not available to the PISP up to the point of execution for payments executed in future. Bulk/batch payments have been deemed out of scope because they can involve multiple debtor accounts. Art. 36(1)(c) RTS appears to contemplate a single payment transaction from a single payment account. With respect to future dated payments and standing orders, our assumption is that a yes/no response at the point of initiation of these payment orders is of little or no utility to a PISP as it not contemporaneous with execution.

4. Detailed Product Requirements

Requirements categorised as ‘M'(Must Have) or ‘S'(Should Have) as per the MoSCoW ratings will be in scope for delivering the minimum viable product. All other requirements are listed for future consideration.

5. Regulatory references

5.1 RTS Reference

Article 36 Data exchanges

1. Account servicing payment service providers shall comply with each of the following requirements:
(a)  they shall provide account information service providers with the same information from designated payment accounts and associated payment transactions made available to the payment service user when directly requesting access to the account information, provided that this information does not include sensitive payment data;
(b)  they shall, immediately after receipt of the payment order, provide payment initiation service providers with the same information on the initiation and execution of the payment transaction provided or made available to the payment service user when the transaction is initiated directly by the latter;
^[3](c) they shall, upon request, immediately provide payment service providers with a confirmation in a simple ‘yes’ or ‘no’ format, whether the amount necessary for the execution of a payment transaction is available on the payment account of the payer.

5.2 EBA Opinion

OPINION OF THE EBA ON THE IMPLEMENTATION OF THE RTS ON SCA AND CSC

The below are EBA opinion on Article 36 related to CoF access by PISP
12. Reference to Table 1

^[1] 22. Furthermore, Article 36(1)(b) of the RTS states that ASPSPs shall provide PISPs ‘with the same information on the initiation and execution of the payment transaction provided or made available to the payment service user’. In addition, Article 36(1)(c) of the RTS requires ASPSPs to provide immediate confirmation of whether or not there are funds available at the provider’s request, in a ‘yes or no’ format. The EBA wishes to clarify that Article 36(1)(c) applies to PSPs including CBPIIs and PISPs, rather than solely CBPIIs.

23. The EBA would also like to clarify that the combination of Article 36(1)(b) and (c) establishes legally binding requirements that are aimed at ensuring that the provider initiating a payment has the information it needs to initiate a payment as requested by the PSU. The yes/no answer will help the PISP to manage the risk it may face if, following the initiation of the payment, it transpires that the payment cannot be executed. It may not be possible to assess this risk with only the information received under Article 36(1)(b) of the RTS.

24. Neither PSD2 nor the RTS make any distinction between payments processed through real- time booking or through delayed (or batch) booking. However, in practical terms, PISPs may have a particular interest in seeking reassurance as to the likelihood that the payment will be executed in the latter case, given that in the absence of a real-time booking system there might be more uncertainty on the status of the initiated transaction.

^[4]25. In this context, the EBA considers that the ASPSP, in determining whether to give a yes or no response to the request for confirmation required under Article 36(1)(c), needs to determine whether or not there are funds available taking into account not only the balance available but also any overdraft and also any other data that the ASPSP uses to determine whether or not to execute a payment of one of its own customers, for instance any incoming/outgoing payments that will affect the balance or overdraft. psr17

26. In the event that the ASPSP does not have a system that enables it to adequately respond to the confirmation request sent by the provider initiating the payment, then the ASPSP should give PISPs the possibility of accessing the necessary data themselves, so as to allow them to make their own judgements on the sufficient availability of funds.

5.3 Draft FCA Approach

17.26 SCA-RTS Article 36(1)(c) requires an ASPSP to respond to a request from a PSP with an immediate ‘yes’ or ‘no’ confirmation as to whether the amount necessary for execution of a payment transaction is available on the payer’s payment account. While regulation 68 of the PSRs 2017 (Article 65 of PSD2) is specific to transactions involving CBPIIs, the EBA Opinion clarifies that provision of the ‘yes’ or ‘no’ confirmation also applies to requests received from PISPs to help them manage the risk of non-execution.

17.27 When determining its response to a PISP’s ‘yes’ or ‘no’ request, the ASPSP should take into account the same information (eg available balance, agreed overdraft, incoming and outgoing funds) it would consider if the customer was executing a payment transaction directly with the ASPSP. The ASPSP should say ‘yes’ if it would execute a payment instruction given by a customer directly.

17.28 The EBA Opinion also sets out that where an ASPSP does not have a system that enables it to adequately respond to the confirmation request sent by a PISP, it should be possible for a PISP to request information related to the availability of sufficient funds. The ASPSP should provide or make available to the PISP the same information the ASPSP would use itself to determine the ‘yes’ or ‘no’ response.

17.29 Where a PISP intends to make such a request, we expect the PISP to obtain the payer’s explicit consent in advance, in line with regulation 97 of the PSRs. In our view, there is no requirement for the PISP to have additional authorisation or registration as an AISP for this purpose.

5.4 PSR

Disapplication of certain regulations in the case of low value payment instruments

^[8]65(3) Subject to paragraph (2)(b), regulations 76 (payment service provider’ s liability for unauthorised transactions) and 77(1) and (2) (payer’s liability for unauthorised transactions) apply to electronic money unless the payer’s payment service provider does not have the ability under the contract to—

(a) freeze the payment account on which the electronic money is stored; or

(b) stop the use of the payment instrument.

^[6]68 (3) The conditions are that—

(a) the payer has given explicit consent to the payment service provider to request the confirmation;

^[7]68 (5) The conditions are that—

(b) before the account servicing payment service provider receives the first request under paragraph (2) 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.

Access to payment accounts for payment initiation services

69.—(1) This regulation applies only in relation to a payment account which is accessible online.

^[2](2) Where a payer gives explicit consent in accordance with regulation 67 (consent and withdrawal of consent) for a payment to be executed through a payment initiation service provider, the payer’s account servicing payment service provider must—

(a) communicate securely with the payment initiation service provider in accordance with the regulatory technical standards adopted under Article 98 of the payment services directive;

(b) immediately after receipt of the payment order from the payment initiation service provider, provide or make available to the payment initiation service provider all information on the initiation of the payment transaction and all information accessible to the account servicing payment service provider regarding the execution of the payment transaction;

(c) treat the payment order in the same way as a payment order received directly from the payer, in particular in terms of timing, priority or charges, unless the account servicing payment service provider has objective reasons for treating the payment order differently;

(d) not require the payment initiation service provider to enter into a contract before complying with the preceding sub-paragraphs.

(3) A payment initiation service provider must—

(g) not use, access or store any information for any purpose except for the provision of a payment initiation service explicitly requested by a payer;

Consent for use of personal data

^[10]97. A payment service provider must not access, process or retain any personal data for the provision of payment services by it, unless it has the explicit consent of the payment service user to do so.

Authentication

^[9]100.—(1) A payment service provider must apply strong customer authentication where a

payment service user—

(a) accesses its payment account online, whether directly or through an account information service provider;

(b) initiates an electronic payment transaction; or

(c) carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.