Okay LogoOkay Logo

PSD2 SCA Compliance & How You Can Prepare for the Deadline



As a bank or PSP, you have to be ready to test your PSD2 compliance with strong customer authentication under the Commission Delegated Regulation before the deadline on the 14th of March 2019. A good place to start for a Single Device SCA is with our own - Okay This.

General Obligations for Access Interfaces

The Commission Delegated Regulation (EU) 2018/389 of 27 November 2017 with regard to and common and secure open standards of communication (PSD2 RTS on SCA) Article 30 states:This testing facility should be made available no later than 6 months before the application date referred to in Article 38(2) or before the target date for the market launch of the access interface when the launch takes place.

Understanding the Final Regulatory Technical Standards

In a previous blog post, we and why is important in the current environment. The European Payment Council (EPC) has published a very helpful that explains the various areas of compliance which must be taken into consideration by the players in the new European payment market starting from September 2019.

Of particular interest is the explanation of the (SCA) and the exemptions to SCA, which under certain assumptions are allowed under (PSD2).The 3 authentication elements of SCA are:

  • Knowledge: Something only the user knows(PIN, password, etc)
  • Possesion: Something only the user possesses (a card, a mobile phone, etc)
  • Inherence: Something the user is (biometric, identification like fingerprint, iris or voice recognition)

Authentication Requirements

Where payment service providers apply SCA, the authentication shall be based on two or more of these elements and shall result in the generation of an authentication code. The authentication code has to fulfill the following requirements:

  • Strong customer authentication’ means an authentication based on the use of two or more elements categorized as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data’; ()
  • No reuse of authentication codes allowed
  • No information on any of the elements referred to above can be derived from the disclosure of the authentication code
  • It shall not be possible to generate a new authentication code based on the knowledge of any other authentication code previously generated
  • The authentication code cannot be forged

Exemptions from applying SCA are subject to specified and limited conditions based on the level of risk, the amount, and the recurrence of the payment transaction and of the payment channel used for its execution.

In order to understand the full picture of the authentication requirements of PSD2, it is important to distinguish between the MANDATORY obligations and the OPTIONAL exemptions under the PSD2.

There are 3 main payment “Authentication Roads” as defined by PSD2 security requirements and risk balancing rules, namely:

  • Payments based on Strong Customer Authentication (SCA)
  • Payments based on Transaction Risk Analysis (TRA) in Real Time
  • Payments based on Other Exemption provisions

SCA is an indispensable and mandatory requirement (In the PSD2 RTS on SCA it is requirement 1), while TRA and the other exemptions are possible options, but only under the certain assumptions.

Business models taking advantage of the exceptions, such as using TRA, cannot exist alone without SCA, while a SCA based business model can exist without TRA and the other exemption-based approaches.

These exemptions are allowed given that the Payment Service Provider (PSP) can switch immediately from the exemption-based method to SCA when the PSP exceeds the acceptable fraud rate (ETV) as defined in the Annex, (cf. PSD2 RTS on SCA requirements 14 and 18.2b).

Is should be noted that there are exemptions that focus on low risk payments such as white-listed recipients, contactless small payments (below 50 euros or aggregated 150 euros since last time SCA was used), transfer between the end user’s own accounts, etc.

SCA and SEPA Instant Credit Transfers

Every bank and PSP should be aware that payments based on SCA are the only appropriate way to initiate SEPA Instant Credit Transfers. The reason is the time constraint of maximum 10 seconds in transmission time between the sender submitting the payment until the receiver gets the money throughout the cross-border payment area of Europe.

Reactive fraud prevention mechanisms in the backend processing of payments can simply not fit into the instant delivery compliance rules. With SEPA Instant Credit Transfers, fraud must be fought in the front-end device of the sender, and SCA with the dynamic linking requirement provides the right security quality for this purpose.

SCA Dynamic Linking

PSD2 RTS on SCA Article 5.2b states: There is an explicit requirement that Dynamic Linking safeguards the privacy-protected display of end-user transaction details throughout the authentication process.

  • Extra element for all remote transactions:A unique authentication code which dynamically links the transaction to a specific amount and a specific payee (for remote internet and mobile payments)

This means that the new compliance requires banks and PSPs to get these technical approaches evaluated:

  • Either deploy dedicated end-user hardware devices with a separate display and keypad
  • Or to obtain a software-based security technology that closes the security gap of allowing equipment, which also meets the security goal of What-You-See-Is-What-You-Sign

Protectoria offers a compliant SCA solution for a single smartphone user experience. The security solution runs in a dynamic Trusted Execution Environment created in the application layer of the (BYOD) device and includes an embedded cryptographic watermark as a proof of the right end user’s transaction verification with traceability.The solution is available as or as licensed technology, the Protectoria Secure Mobile Platform.

Independent Security Evaluation and payment security policy documentation

Article 5.1 of PSD2 states: For authorization as a payment institution, an application shall be submitted to the competent authorities of the home Member State, together with the following: (5.1j) a security policy document, including a detailed risk assessment in relation to its payment services and a description of security control and mitigation measures taken to adequately protect payment service users against the risks identified, including fraud and illegal use of sensitive and personal data.PSD2 RTS on SCA Article 3.1 states: Security evaluation of implemented SCA, TRA and the other exception-based methods shall be subject to independent and competent safety audit. Independently, it means expertise in IT security and payment that is operationally independent, in or out of, of the PSP.

Article 3 of the PSD2 RTS on SCA requires an operationally independent auditor with expertise in IT security and payments that is not required to be external for the general audit of all the security measures foreseen in the PSD2 RTS on SCA (both SCA and others).Further, in paragraph 2 of Article 3 in case of a PSP making use of the exemption under Article 18 (TRA) explicitly requires an independent and qualified external auditor to carry out the first audit, and at least every 3 years thereafter in relation to this exemption.

Consequences of Noncompliance

Noncompliant payment service providers must refund any claimed fraud by the payment user within 24 hours, with no questions asked.

  • PSD2 foresees that the payer can claim full reimbursement from their PSP in case of an unauthorized payment if there was no SCA measure in place and if the payer did not act fraudulently.

Deadlines to Consider

PSD2 RTS on SCA Article 38 states:This Regulation shall apply from 14 September 2019.

However, paragraphs 3 and 5 of PSD2 RTS on SCA Article 30 shall apply from 14 March 2019.Account servicing payment service providers shall make available a testing facility, including support, for connection and functional testing to enable authorized payment initiation service providers, payment service providers issuing card-based payment instruments and account information service providers, or payment service providers that have applied for the relevant authorization, to test their software and applications used for offering a payment service to users. This testing facility should be made available no later than 6 months before the entry into force of the PSD2 RTS on SCA. Therefore, the testing facility must be available from 14 March 2019 on.