As an enhanced security measure, PSD2 requires that ASPSPs apply strong customer authentication (SCA) where a payer initiates an electronic payment, including via a PISP, unless an exemption applies.
Other pages in this section
As an enhanced security measure, PSD2 requires that ASPSPs apply strong customer authentication (SCA) where a payer initiates an electronic payment, including via a PISP, unless an exemption applies. SCA must be based on two or more factors which are categorised as knowledge, possession and inherence. SCA however may not always be easy to apply to offer user-friendly services and hence there needs to be a balance between enhanced security and the need for user-friendliness and accessibility of payments initiated through a PISP.
Keeping this in mind, the SCA RTS include a number of exemptions from the obligation to apply SCA, based on factors such as the level of risk, amount, recurrence and the payment channel used for the execution of the payment transaction.
However, the application or non application of SCA and the exact implementation of an SCA exemption is at the ASPSP’s discretion. For some exemptions (e.g. contactless, parking/transport) an ASPSP may not be able to identify whether an exemption is applicable to the particular transaction, unless relevant information is provided by the PISP. Furthermore, there is currently no industry harmonisation on how the exemption is implemented by the ASPSP (soft authentication/no authentication). ASPSPs who want to implement SCA exemptions will still need some means to securely identify the PSU.
This paper proposes that capabilities be introduced into the OB standards to allow PISPs to provide sufficient information about a transaction and about the PSU (if available) to enable the ASPSP to determine whether or not the exemptions are applicable.
This proposition has been expanded to apply to the following exemptions under the SCA RTS:
This paper has factored in inputs, as listed below, received through OB industry engagement and also through market needs listed within the API Evaluation group recommended functionalities.
Retailers believe that the payment context and related exemption type/SCA request must be added. Typically for example, merchants and/or PISPs within the payment journey would be able to indicate to an ASPSP if an initiated payment may qualify for the contactless or remote low value exemptions, or confirm the transaction’s value, whether it is recurring or if it is occurring within a POS environment. This could assist the ASPSP as a factor in determining whether to apply an available exemption, in conjunction with other factors, such cumulative amount or amount and number since last SCA.
Moreover, ASPSP may want to support a functionality that enables them to identify a PSU for subsequent payment initiation requests from PISPs without the need to authenticate the PSU. ASPSPs who would want to implement this functionality will need to consider specific exemption implementation, as well as, contractual arrangements corresponding to this functionality, where applicable.
This proposition covers the capabilities which will allow the PISPs to provide sufficient information to the ASPSP to help trigger/provision an exemption. This will however not guarantee an application/non application of SCA from the ASPSP, as the ultimate decision on this is with the ASPSP.
The OB standards must be extended to support the following:
The following are some example use cases which have been considered for this proposition.
The EBA has clarified in its opinion that only the payer’s ASPSP can apply SCA or decide whether or not an exemption applies. The primacy of this principle must be reflected in the OB standards (but of course the principle could be altered via a market facing agreement).
It has also clarified via the EBA Q&A tool that neither an AISP nor PISP can create or amend a trusted beneficiary list itself, because this list must be maintained by the ASPSP. Put differently, the AISP/PISP cannot access the list in “write mode”. As such, for the purposes of this proposition, the consideration of trusted beneficiaries is limited to product requirements 1, 2 & 3.
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).
The following metrics will be required to measure adoption:
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.
Supporting data that can be provided by the PISP to the ASPSP as part of a payment initiation to request an exemption. Application of SCA and the use of an available exemption is ultimately in the domain of the ASPSP. This list is not exhaustive and will be updated as more use cases emerge.
*This functionality may require consideration to be given in respect of contractual arrangements.
The following table is taken ‘as-is’ from the published roadmap which was limited to the Trusted Beneficiary exemption. However, this proposition has been expanded to apply to the other exemptions under the SCA RTS as explained in Section 2:
Article 11 Contactless payments at point of sale
Payment service providers shall be allowed not to apply strong customer authentication, subject to compliance with the requirements laid down in Article 2, where the payer initiates a contactless electronic payment transaction provided that the following conditions are met:
(a) the individual amount of the contactless electronic payment transaction does not exceed EUR 50; and
(b) the cumulative amount of previous contactless electronic payment transactions initiated by means of a payment instrument with a contactless functionality from the date of the last application of strong customer authentication does not exceed EUR 150; or
(c) the number of consecutive contactless electronic payment transactions initiated via the payment instrument offering a contactless functionality since the last application of strong customer authentication does not exceed five.
Article 12 Unattended terminals for transport fares and parking fees
Payment service providers shall be allowed not to apply strong customer authentication, subject to compliance with the requirements laid down in Article 2, where the payer initiates an electronic payment transaction at an unattended payment terminal for the purpose of paying a transport fare or a parking fee.
Article 13 Trusted beneficiaries
Payment service providers shall apply strong customer authentication where a payer creates or amends a list of trusted beneficiaries through the payer’s account servicing payment service provider.
Payment service providers shall be allowed not to apply strong customer authentication, subject to compliance with the general authentication requirements, where the payer initiates a payment transaction and the payee is included in a list of trusted beneficiaries previously created by the payer.
Article 14 Recurring transactions
Payment service providers shall apply strong customer authentication when a payer creates, amends, or initiates for the first time, a series of recurring transactions with the same amount and with the same payee. Payment service providers shall be allowed not to apply strong customer authentication, subject to compliance with the general authentication requirements, for the initiation of all subsequent payment transactions included in the series of payment transactions referred to in paragraph 1.
Article 16 Low-value transactions
Payment service providers shall be allowed not to apply strong customer authentication, where the payer initiates a remote electronic payment transaction provided that the following conditions are met:
(a) the amount of the remote electronic payment transaction does not exceed EUR 30; and
(b) the cumulative amount of previous remote electronic payment transactions initiated by the payer since the last application of strong customer authentication does not, exceed EUR 100; or
(c) the number of previous remote electronic payment transactions initiated by the payer since the last application of strong customer authentication does not exceed five consecutive individual remote electronic payment transactions.
The opinion of the EBA on the Implementation of the RTS of SCA is stated as follows:
Type of submitter
On the access to trusted beneficiaries lists (RTS Art 13) by TPPs in write mode
Do the TPPs have the right to access trusted beneficiaries lists in write mode?
Background on the question
Article 13(1) (“1.Payment service providers shall apply strong customer authentication where a payer creates or amends a list of trusted beneficiaries through the payer’s account servicing payment service provider.”) of the RTS on strong customer authentication and secure communication seems to allow for the creation/amendment of the trusted list managed by ASPSP through TPPs. If this interpretation is correct, we also have differentiated views depending on the type of TPP.
This question is relevant for our national API provider to know if a feature needs to be implemented.
Article 13(1) of the Commission Delegated Regulation (EU) 2018/389, sets out that a payer can create or amend a list of trusted beneficiaries through its account servicing payment service provider. Therefore, the creation or amendment of such a list through the services of a PISP or an AISP is not possible. A list that is accessible to a PISP or to an AISP in write mode does not fulfil the requirements of the exemption under Article 13(2) of the Delegated Regulation.
In addition, and as stated in the EBA Opinion on the implementation of the regulatory technical standards on strong customer authentication (SCA) and common and secure communication, EBA-Op-2018-04, June 2018, the payment service provider (PSP) applying SCA is the PSP that issues the personalised security credentials, namely the ASPSP. Consequently, it is also the same provider that decides whether or not to apply an exemption, such as the beneficiary list exemption, and not the AISP or PISP.