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 PSD2 Compliant Strong Customer Authentication - Okay This.
General Obligations for Access Interfaces
The Commission Delegated Regulation (EU) 2018/389 of 27 November 2017 with regard to regulatory technical standards for strong customer authentication 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 explained PSD2 and why is important in the current environment. The European Payment Council (EPC) has published a very helpful PSD2 paper 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 Strong Customer Authentication (SCA) and the exemptions to SCA, which under certain assumptions are allowed under Payment Service Directive 2 (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)
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’; (ref the PSD2 text, Definitions 30)
- 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 BYOD (bring your own device) 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 asSaaS through our website 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.
- The payment service providers (PSPS)
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.