Propositions

P8 • Trusted beneficiaries exemption under SCA

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

1. Version control

VersionDateAuthorsComments
v0.1OBIE API Delivery TeamDraft for internal review.
v0.218 Dec 2018 OBIE API Delivery TeamVersion for 1st round of public consultation
v0.304 Feb 2019 OBIE API Delivery TeamUpdate based on 1st round of consultation feedback for second round of public consultation
v1.019 Feb 2019 OBIE API Delivery TeamNo changes from the second round of public consultation. Submitted for approval at IESG

2. Roadmap item definition

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:

3. Market analysis

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. 

4. Product requirements

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:

  1. After the first payment initiation through a PISP, ability for ASPSP to send a unique PSU identifier to the PISP. This gives the ability for ASPSPs to identify the PSU using this identifier for subsequent payment initiations and support SCA exemptions (in the competitive space) which may not require the PSU to authenticate with the ASPSP.
  2. Ability for the PISP as part of a payment initiation to explicitly request the application of a particular SCA exemption and send the corresponding supporting data for the type of exemption to the ASPSP. 
  3. Ability for the PISP to explicitly request the application of SCA, even where the transaction may otherwise qualify for an SCA exemption. 

5. Customer use cases

The following are some example use cases which have been considered for this proposition.

IDSingle Future Dated PaymentsMet
UC1As a TPP providing parking services, I would like to request for a parking specific SCA exemption to the ASPSP of the customer making the payment.Fully
UC2As a retailer who has been previously setup as a trusted beneficiary by the customer, I would like to have the ability to request the customer’s ASPSP to apply SCA for any payments deemed as high risk as per my internal risk analysis.Fully
UC3As a customer using a TPP’s train ticketing service, I would like to setup my ASPSP account as my payment method as part of my first payment I make through the TPP app so that I can make subsequent payments even through unattended Kiosk’s of the TPP without requiring to authenticate with the ASPSP. Note: This is subject to the ASPSP implementing the SCA exemption in a specific manner and may require agreements between the TPP and the ASPSP. After the first payment initiation through a PISP, the ASPSP can send a unique PSU identifier to the PISP. For subsequent payments, the ASPSP uses this identifier to identify the PSU and does not require the PSU to physically authenticate with the ASPSP.Fully*

6. Regulatory references

6.1 Strong Customer Authentication

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).

6.2 Trusted Beneficiary exemption

It has also clarified via the EBA Q&A[1] 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. 

7. 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).

  1. Does the proposition meet the use cases from a PSU and a TPP perspective (from both an outcome and risk point of view)?
  2. Is the proposition implementable at reasonable cost?
  3. Does the proposition comply with all relevant regulations?

8. Considerations

8.1 Assumption

8.2 Dependencies

8.3 Constraints

9. Measuring adoption

The following metrics will be required to measure adoption:

  1. Volume of payment transactions where SCA exemption is requested, categorised by the type of exemption requested. 
  2. Volume of payment transactions where SCA was specifically requested by the TPP. 

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.

IDDescriptionMoSCoWRationaleRegulatory AlignmentImplementation
1After the PSU has initiated a payment initiation through a PISP, the OBIE’s Solution(s) must allow the ASPSP to identify a PSU as part of subsequent payment initiation request from that PISP without the PSU having to provide any customer identification details to the PISP. 

Note: After the first payment initiation through a PISP, the ASPSP can send a unique PSU identifier to the PISP.This is subject to the ASPSP implementing the SCA exemption in this specific manner and may require agreements between the TPP and the ASPSP. 		MCustomerOptional
2The OBIE’s Solution(s) must allow a PISP to request a specific SCA exemption for a payment initiation and send corresponding supporting data to the ASPSP for the type of exemption (e.g. transport, parking, contactless, trusted beneficiary).
Note: Please see 10.2 below for details.
For low value payments and contactless, the ASPSP will manage the limit conditions (such as 5 payments, < €30 / €50 payment or <€100/ €150 between 2 SCAs) as specified in RTS Article 11 and 16.		MCustomerOptional
3The OBIE’s Solution(s) must allow a PISP to request the ASPSP to apply an SCA to a payment initiated which would otherwise qualify for one of the SCA exemptions.

Note: This is a case where the PISP, based on their own risk analysis, may want to request the ASPSP to apply an SCA for transactions where the ASPSP would have otherwise applied an exemption.    		MCustomerOptional
4The OBIE’s Solution(s) must allow ASPSPs to provide MI on metrics and adoption as per section 9 above.MRegulatoryCMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA,
section 2.1.6		Mandatory (if option is implemented)

10.2 Supporting data for SCA exemption request

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.

Supporting dataDescription
Payment contextTo indicate the customer facing service which has resulted in the payment initiation. For example:
• Bill Payment.
• Parking.
• P2P payment.
• Ecommerce Services.
• Ecommerce Goods.
• Kiosk.
• Contactless Travel.
Merchant categoryIndustry standard to define the type of merchant.  
Recurrence identifierIf the payment is recurring, then this is the unique identifier of the previous payment occurrence, so that the ASPSP can verify that the PISP, amount and the payee are the same as the previous occurrence. 
Customer authenticatedTo indicate whether the PSU was subject to SCA performed by the TPP*.
Customer identifier known to the ASPSPReceived from the ASPSP as part of previously initiated payment, to be used by the ASPSP to identify a PSU for subsequent payment initiation requests from that PISP.*

*This functionality may require consideration to be given in respect of contractual arrangements.

10.3 Roadmap item definition

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: 

DescriptionRationaleAligns with
P8 – Trusted beneficiaries exemptions under SCAScope Item description: 
Alignment of functionality to Trusted beneficiaries and recurring payments SCA exemptions under finalised RTS (currently Article 13 of the draft RTS). 

Pending finalisation of the draft RTS functionality could include: 
• Extension of write (PIS) functionality of the OB R/W
APIs to enable TPPs to execute payments to payees on the PSU’s trusted beneficiary list (held at the ASPSP) under SCA exemption (as applied under the security policy of the ASPSP’s customer facing interface); and
• Enablement of OB standards to allow TPPs to add, amend and remove payees on their trusted beneficiary list held at the ASPSP on behalf of the PSU. 

Key activities:
• A discovery phase by the OBIE to understand the variety of trusted beneficiary models used in practice, the requirements under RTS and an assessment of alternative methods for initiating payments under SCA exemption (including for example recurring payments) to create the business requirements for the standards.
• The development of standards by the OBIE for the products and functionality referred to above.
• The implementation of those standards by the CMA9 for Release 3. 		Regulatory alignment:
Fulfills the requirements of the Order by aligning with PSD2.

Open Banking adoption:
Extends functionality of OB Standards use cases to SCA exempt payments and thereby greater utility for TPPs.

Consumer / SME utility:
Consumers would be able to benefit from more convenient regular payment, e-commerce and account sweeping propositions.

Security / Integrity:
Consumers would be able to execute payments conveniently without putting cards on file and better manage their trusted beneficiaries.

10.4 Regulatory references

10.4.1 RTS reference

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.

10.4.2 EBA opinion

The opinion of the EBA on the Implementation of the RTS of SCA is stated as follows:

  1. With regard to the exemption on trusted beneficiaries (Article 13), the EBA clarifies that the exemption is not limited to credit transfers and may apply to cards through the payer’s PSP, upon the payer’s confirmation. The EBA also clarifies that the payee’s PSP cannot apply this exemption and that a payee could not have such a list for the purpose of the exemption (e.g. cards on file).
10.4.3 EBA Q&A[1]

Type of submitter

Competent authority

Subject matter

On the access to trusted beneficiaries lists (RTS Art 13) by TPPs in write mode

Question

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.

EBA answer

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.

Link

EBA website