- Question ID
-
2023_6873
- Legal act
- Directive 2015/2366/EU (PSD2)
- Topic
- Strong customer authentication and common and secure communication (incl. access)
- Article
-
80
- COM Delegated or Implementing Acts/RTS/ITS/GLs/Recommendations
- Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication
- Article/Paragraph
-
36(1)(b)
- Name of institution / submitter
-
Bank of Spain
- Country of incorporation / residence
-
España
- Type of submitter
-
Competent authority
- Subject matter
-
PISP payment order cancellation due to fraud prevention reasons
- Question
-
Due to fraud prevention reasons, could an ASPSP (Account Servicing Payment Service Provider) block a payment order initiated through a PISP (Payment Initiation Service Provider) despite having informed the PISP immediately upon authentication, that the payment was going to be executed (i.e., after having provided the PISP with the code ACSC (AcceptedSettlementCompleted) under the Berlin Group Standard)? In that scenario who should bear the liability if the payment is not executed but, nonetheless, the payee delivered the good or service promptly after being informed by the PISP of the successful initiation of the payment?
Would the answer be different if the ASPSP had simply confirmed the sufficiency of funds as stated in the EBA Opinion on the implementation of the RTS on SCA and CSC (EBA-Op-2018-04)?
- Background on the question
-
We would like to consider four relevant use cases where, a SEPA D+1 credit transfer is initiated through a PISP and SCA is successfully applied. A description of each use case is given below:
a) After having the ASPSP provided to the PISP the confirmation that the payment will be executed (code ACSC), the payer claims to be a victim of a fraud and requests the ASPSP to cancel the payment. As the request takes place before the execution of the payment, the latter does not take place.
b) After having the ASPSP provided to the PISP the confirmation that the payment will be executed (code ACSC), during the payment processing, ASPSP's anti-fraud controls, based on objectively justified and duly evidenced reasons, provides an early warning about the possibility of an unauthorized or fraudulent payment transaction initiation. Consequently, the ASPSP decides, in a preventive manner, to block the payment account and cancel any other pending payments, irrespective of having being initiated through a PISP or other channels.
c) +d) Either of the cases above but after having the ASPSP provided to the PISP with only a YES answer regarding the sufficiency of funds or with a code reflecting such a sufficiency
Article 66(4)(b) of PSD2 establishes that “The account servicing payment service provider shall immediately after receipt of the payment order from a payment initiation service provider, provide or make available 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 to the payment initiation service provider”.
Furthermore, Commission Delegated Regulation (EU) 2018/389 and, in particular, EBA’s Opinion EBA-Op-2018-04, develops the provisions of the abovementioned article concluding that the ASPSPs shall provide the PISP, immediately after receipt of the payment order, the necessary information to initiate the payment, including a confirmation (yes/no) of the availability of funds; this information should 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.
Additionally, in accordance with Recital 29 PSD2, payment initiation services enable the payment initiation service provider to provide comfort to a payee that the payment has been initiated in order to provide an incentive to the payee to release the goods or to deliver the service without undue delay.
However, there are no provisions about the possibility of a duly (in principle) justified not execution of a payment, after the AISP has provided to the PISP the confirmation that the payment will be executed.
On the other hand, article 80.2 of PSD2 establishes that “Where the payment transaction is initiated by a payment initiation service provider […] the payer shall not revoke the payment order after giving consent to the payment initiation service provider to initiate the payment transaction […]”. Then according to article 80.5 “After the time limits laid down in paragraphs 1 to 4, the payment order may be revoked only if agreed between the payment service user and the relevant payment service providers. In the case referred to in paragraphs 2 and 3, the payee’s agreement shall also be required”.
However, in the exposed cases there is not a proper revocation since the payer assures it was not him who ordered the payment transaction.
The described cases could lead to an undesirable situation in the event the PISP had already informed about the successful initiation of the payment to the payee who immediately afterwards delivered the corresponding goods or services.
- Submission date
- Final publishing date
-
- Final answer
-
According to Article 64 of PSD2, “Member States shall ensure that a payment transaction is considered to be authorised only if the payer has given consent to execute the payment transaction. […] 2. Consent to execute a payment transaction […] shall be given in the form agreed between the payer and the payment service provider. […] Consent may be withdrawn by the payer at any time, but no later than at the moment of irrevocability in accordance with Article 80. […] The procedure for giving consent shall be agreed between the payer and the relevant payment service provider(s)”.
In use case (a) described by the submitter, where the payer claims that it did not authorise a payment order and requests the account servicing payment service provider (ASPSP) to cancel the payment order before the transaction is executed, the ASPSP must assess based on the elements available to it whether the transaction was authorised or not. Where the transaction was authorised, according to Article 80 of PSD2, the payer can only revoke the payment order after having given consent to the payment initiation service provider (PISP) to initiate the payment transaction, “if agreed between the payment service user and the relevant payment service providers” (Article 80(5)). After this time limit, and where the payment transaction is initiated by a PISP, “the payee’s agreement shall also be required” (Article 80(2) and (5)) to revoke the payment order. If there is an agreement of the relevant parties involved, which is a legal prerequisite for a revocation of a payment order by the payer, the question of liability does not arise.
Use case (b) is a different situation. In the scenario described by the submitter, the ASPSP confirmed to the PISP that the payment would be executed but, based on its fraud prevention tools, the ASPSP takes the unilateral decision to block the payment order received from the payer before its execution.
Article 79 PSD2 states that “where all of the conditions set out in the payer’s framework contract are met, the payer’s account servicing payment service provider shall not refuse to execute an authorised payment order irrespective of whether the payment order is initiated by a payer, including through a payment initiation service provider, or by or through a payee, unless prohibited by other relevant Union or national law”.
The principle is therefore that a payment order given by the payer must be executed by the ASPSP. This provision, together with Article 80, guarantees the legal certainty of financial transactions and protects the payer and the payee. PSD2 provides however explicitly for some exceptions, which are the presence of ‘factual mistakes’ (Article 79(1)), the breach of the framework contract’s conditions or situations where relevant Union or national law would prohibit the order’s execution (Article 79(2)). Article 79(1) provides some procedural requirements for cases where the PSP refused the execution.
PSD2 did not envisage explicitly the case where the refusal to execute the order would be unilaterally decided by the ASPSP in order to protect the payer against a risk of fraud. PSD2 does not regulate either what a legitimate suspicion of fraud can be.
Considering the above, where an ASPSP refuses to execute an authorised and legitimate payment order (e.g, in the case where the ASPSP transaction monitoring flags a legitimate payment as suspicious and the ASPSP refuses to execute the payment order), this can expose the ASPSP to liability for refusing to execute the payment order. In case of challenge, and without prejudice to other relevant Union or national law, it would be for a court to decide on the liability of the ASPSP on a case-by-case basis.
PSD2 is silent as regards the potential liability of the ASPSP towards the PISP for having returned to the PISP an ACSC code, where in fact the payment was not executed. Such aspects remain subject to national law provisions on liability. In the alternative scenario mentioned by the submitter, where the ASPSP does not return to the PISP an ACSC code, but simply a ‘yes’ or ’no’ answer on whether the amount necessary for the execution of a payment transaction is available on the payment account of the payer, in accordance with Article 36(1)(c) of the Commission Delegated Regulation (EU) 2018/389, the situation as regards liability of the ASPSP towards the PISP would be different, as the ‘yes’/’no’ answer is not a confirmation that the payment will be executed.
Disclaimer: The answer clarifies provisions already contained in the applicable legislation. They do not extend in any way the rights and obligations deriving from such legislation nor do they introduce any additional requirements for the concerned operators and competent authorities. The answers are merely intended to assist natural or legal persons, including competent authorities and Union institutions and bodies in clarifying the application or implementation of the relevant legal provisions. Only the Court of Justice of the European Union is competent to authoritatively interpret Union law. The views expressed in the internal Commission Decision cannot prejudge the position that the European Commission might take before the Union and national courts.
- Status
-
Final Q&A
- Answer prepared by
-
Answer prepared by the European Commission because it is a matter of interpretation of Union law.
Disclaimer
The Q&A refers to the provisions in force on the day of their publication. The EBA does not systematically review published Q&As following the amendment of legislative acts. Users of the Q&A tool should therefore check the date of publication of the Q&A and whether the provisions referred to in the answer remain the same.