Shall payers be able to make use of payment initiation service providers for transmitting all types of credit-transfer based online payment orders from their payment accounts?
There are multiple types of payment transactions that account servicing payment service providers (ASPSPs) make available for payers to perform online. These payment transactions have different characteristics such as how fast they reach the payee, which unique identifier the payee has been assigned and how much they cost for the payer to send and for the payee to receive. Some examples are:
1. Domestic transactions, where the payee's unique identifier is a national bank account number
2. SEPA transactions, where the payee's unique identifier is an IBAN
3. SCT Inst, where the payee's unique identifier is an IBAN
4. Giro payments, where the payee's unique identifier is a domestic giro number
5. Mobile payments, where the payee's unique identifier is their mobile phone number (or a number looking like a phone number for legal persons)
While the first four types of payment transactions are usually supported in the ASPSPs' Article 30 RTS (on SCA and CSC) access interfaces, mobile payments often are not.
Some ASPSPs provide the mobile payment transfers either in their customer-facing online interface or in a dedicated app with its own separate branding (for the latter, sometimes several ASPSPs in the same Member State jointly offer their respective customers to initiate mobile payments in such an app). The licensed entity offering the service is however each individual ASPSP and the funds are sent from / received to the regular bank accounts serviced by the ASPSP. The mobile payment transfers are credit transfers that make use of a payment system in order for customers of different ASPSPs to be able to make transactions to each other (the payment systems used do not qualify for recital 52, PSD2.) Examples of such dedicated apps include e.g. Swish in Sweden, Bizum in Spain, Bancomat Pay in Italy, etc.
Article 66(1) PSD2 only exempt payment accounts that are not accessible online from where the payer has the right to make use of a payment initiation service provider to obtain payment services. Neither PSD2 nor the RTS on SCA and CSC makes any further exemptions of different payment transaction types. On the contrary, the 2018-04 EBA Opinion on the implementation of the RTS on SCA and CSC even clarified in paragraph 29 “that a PISP has the right to initiate the same transactions that the ASPSP offers to its own PSUs, such as instant payments, batch payments, international payments, recurring transactions, payments set by national schemes and future-dated payments.” As such, the access interfaces under PSD2 should also include mobile payments, provided that such mobile payments are offered to payers of that ASPSP. The fact that an ASPSP may offer mobile payments as part of a separate customer-facing app rather than in its standard mobile banking app does not change this requirement.
According to Article 66(1) of the Directive 2015/2366/EU (PSD2), a payer has the right to make use of a payment initiation service provider (PISP) to obtain payment initiation services, if the payer’s payment account is accessible online.
Article 4(33) of PSD2 defines a ‘unique identifier’ as ‘a combination of letters, numbers or symbols specified to the payment service user by the payment service provider and to be provided by the payment service user to identify unambiguously another payment service user and/or the payment account of that other payment service user for a payment transaction’.
Article 36(4) of the Commission Delegated Regulation (EU) 2018/389 prescribes that PISPs shall provide account servicing payment service providers (ASPSP) with the same information as requested from the Payment Service User (PSU) when initiating the payment transactions directly.
Paragraph 29 of the EBA Opinion on the implementation of the RTS on SCA and CSC (EBA-Op-2018-04) clarifies that a PISP has the right to initiate the same transactions that the ASPSP offers to its own PSUs, such as instant payments, batch payments, international payments, recurring transactions, payments set by national schemes and future-dated payments.
It follows from the above that the PSU should have the right to initiate the same transactions through a PISP, by providing the same information requested by the ASPSP when initiating the payment transactions directly with the ASPSP.
Consequently, for the cases where the ASPSP allows the PSU to initiate payment transactions – either through the ASPSP’s browser environment or a mobile banking app of the ASPSP – using different unique identifiers (including national bank account numbers, IBANs, domestic giro numbers), the PSU should have the right to initiate the same payment transactions through a PISP by using the same unique identifiers. This should apply regardless of the type of interface used by the PISP to securely communicate with the ASPSP (i.e. a dedicated interface or the interface used by the ASPSP for authentication and communication with its PSUs).
However, the case is different for mobile payments that rely on a mobile phone number as a proxy for the payee's unique identifier (such as an IBAN). Such mobile payments entail an additional service (the use of the payee’s mobile number as a proxy for the payee’s unique identifier) that is offered by ASPSP to its PSUs complementary to the underlying transaction that is a conventional transaction, such as a credit transfer. Such additional service is often based on contractual agreements between ASPSPs and a third party operating and maintaining these solutions, including the databased of phone numbers. Whilst the ASPSP should enable PISPs to initiate the underlying conventional transactions, neither the PSD2, nor the Delegated Regulation, require ASPSPs to allow PISPs to initiate mobile payments of the kind described above. However, market participants in a given jurisdiction can agree to allow PISPs to initiate such payments, on an industry-wide or a bilateral contractual basis.