Search for Q&As Submit a question

List of Q&As

Definition of payee for dynamic linking

Article 5 of the RTS on strong customer authentication and secure communication requires the authentication code to be specific to the amount of the payment transaction and the payee.Does it suffice to include a meaningful part of the identifier into the calculation of the authentication code? For instance, would it suffice to include only numeric characters of the IBAN in the calculation of the authentication code?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2019_4556| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 15/02/2019

Dynamic Linking for batch payments

With regards to dynamic linking for a batch of remote electronic payments, should the authentication code be linked to each and every IBAN of all the beneficiaries in a batch file?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2018_4435| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 27/12/2018

Dynamic linking for batch transactions

In relation to payment transactions for a batch of remote electronic payments to one or several payees, please clarify whether the payer needs to be made aware of every payee in the batch?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2018_4415| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 11/12/2018

Data authentication standards

Does a non-remote card payment transaction with a secure, dynamic data authentication of the card (DDA or higher), based on ISO/IEC 7816 (for contact cards) and ISO/IEC 14443 (for contactless card) used with a static PIN meet the requirements of Article 4 of the RTS on Strong Customer Authentication (SCA)?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2018_4110| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 13/07/2018

Scope of ‘initiation of an electronic payment transaction’

Does a card payment transaction, authenticated with a signature at the point of sale, fall under the scope of Article 97 (I) (b) PSD2? Is there a difference if the signature is provided on a paper or on a signature pad (e.g. electronic signature pad or signature capture at a payment terminal)?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2018_4108| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 13/07/2018

Confidentiality of the application cryptogram for EMV transactions

Are EMV (Europay, MasterCard, Visa)  transactions (for which the application cryptogram is not enciphered during its transmission) compliant with the RTS on strong customer authentication?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2018_4054| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 28/06/2018

Compliance with SCA in offline mode on an aircraft without internet connection

How can Strong Customer Authentication (SCA) be applied in an offline environment onboard an airplane when chip and pin cannot be verified with a Point of Sale (POS) device? Specifically, how is dynamic linking achieved in an offline mode for airlines who don't have internet connectivity but instead have a closed wireless network to be able to make purchases onboard an aircraft?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2019_4740| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 24/05/2019

Unsuccessful authentications and declined transactions effect on the counters of cumulative amount and number of consecutive transactions

Do failed authentications or declined transactions increase the counters of cumulative amount or number of hits?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2019_4785| Topic: Other topics| Date of submission: 18/06/2019

Transaction Risk Analysis (TRA) exemption – Time period for calculation of initial fraud rate

What is the relevant time period to use when calculating the initial fraud rate for use when the Strong Customer Authentication (SCA) comes into force?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2018_4044| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 28/06/2018

3 month notification period on interface changes to ASPSPs’ interfaces

Do account servicing payment service providers (ASPSPs) need to adhere to a 3 month notification period for all interface changes, or only for breaking interface changes, as specified in the RTS on on strong customer authentication (SCA) and secure communication (CSC) Article 30 Paragraph 4?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2019_4823| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 09/07/2019

Applicability of exemption under RTS Article 16 for payee’s PSPs (acquirers)

Can an exemption under Article 16 of the RTS on strong customer authentication and secure communication be applied by the payee’s payment service provider (PSP) (the acquirer) for card-based payments?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2018_4242| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 06/09/2018

Applicability of exemption under RTS Article 11 for payee’s PSPs (acquirers)

Can an exemption under Article 11 of the RTS on strong customer authentication and secure communication be applied by the payee's payment service provider (PSP) (the acquirer) for card-based payments?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2018_4241| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 06/09/2018

Contactless counting

For the purpose of counting previous cumulative contactless transactions in order to assess the eligibility of the exemption in Article 11 of the RTS, should contactless transactions initiated outside of the EEA be included?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2018_4227| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 05/09/2018

Contactless payments at point of sale - Applications of the conditions

With respect to Article 11 Paragraph b) of the RTS can we setup control for either 150 € or 5 transactions?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2018_4225| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 05/09/2018

Application of limits for Strong customer authentication (SCA) exemption

How should payment service providers (PSPs) apply the cumulative limits set in Articles 11 and 16 of the RTS on strong customer authentication and secure communication?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2018_4182| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 06/08/2018

Application of the low-value contactless exemption – Calculation of limits at Primary Account Number (PAN) / account level or at device / token level

May the counters for the application of the low-value contactless exemption be calculated at device/token level?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2018_4036| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 28/06/2018

Criteria for the application of the transaction risk analysis (TRA) exemption – Relevant fraud rates

Is only the Payment Service Provider (PSP) applying the TRA exemption required to have a fraud level below the reference fraud rate?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2018_4034| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 28/06/2018

Is the scope of the RTS on strong customer authentication (SCA) and secure communication one-leg or two-leg?

Does the PSD2 requirement on SCA, and subsequently the detailed requirements in the RTS on SCA including the practical usage of the allowed exemptions, apply also to one-leg transactions, with regards to:Transactions with the payer’s payment service providers (PSP) outside the EEA (credit transfers as well as card-based payments)?Credit transfers with the payer’s PSP inside the EEA and the payee’s PSP outside the EEA?Card-based payments with the payer’s PSP (the issuer) inside the EEA and the payee’s PSP (the acquirer) outside the EEA, when the non-EEA acquirer do support SCA?Card-based payments with the payer’s PSP (the issuer) inside the EEA and the payee’s PSP (the acquirer) outside the EEA, when the non-EEA acquirer does not support SCA?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2018_4233| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 06/09/2018

Geographical scope of application of the RTS on strong customer authentication (SCA) and secure communication requirements – ‘Two-leg’ transactions

Is it necessary that issuer, acquirer, cardholder and merchant be all located in the EEA for the RTS on SCA requirements to apply to two-leg transactions?May the issuer use the merchant’s location as a proxy (in lieu of the acquirer’s location)?

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2018_4030| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 28/06/2018

What is considered as a dedicated interface

Payment Service Users (PSUs) communicate with an account servicing payment service provider (ASPSP) via Web using HTTP while mobile PSUs and Third Party Providers (TPPs) via REST Application Programming Interfaces (APIs) but in all cases the processing is done by the same back-end server using the same credentials, authorisations and business logic. In the case of mobile and TPP channels, the APIs are similar and are exposed from the same ASPSP’s gateway. Any issue in the back-end server will result in downtime for all channels. Clarification is required whether this solution is considered as a dedicated interface or not.

COM Delegated or Implementing Acts/RTS/ITS/GLs: Regulation (EU) 2018/389 - RTS on strong customer authentication and secure communication

ID: 2019_4681| Topic: Strong customer authentication and common and secure communication (incl. access)| Date of submission: 25/04/2019

PDF