The European Payment Council (EPC) has published a variety of useful information explaining the various areas of compliance which must be taken into consideration by players in the European payment market starting in September 2019.

Of particular interest is the explanation and the exemptions regarding SCA, as well as the 3 authentication elements of SCA:

• Knowledge: Something only the user knows (PIN, password, etc)
• Possession: 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 fulfil the following requirements:

“Strong customer authentication’ means an authentication based on the use of two or more elements categorised as knowledge, possession and inherence, 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.”

This method will ensure that the user is who they say they are, preventing:

• The reusing of authentication codes
• The forging of authentication codes
• Information of an element being derived from the disclosure of the authentication code
• The possibility of generating new authentication codes based on the knowledge of any other authentication code previously generated

Exemptions from applying SCA are subject to specified and limited conditions based on the level of risk, the amount, 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.

You can read more on the subject with this article written by GPayments.

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, while TRA and the Other Exemptions are possible options, but only under the certain assumptions.

Business models taking advantage of the exceptions cannot exist alone without SCA, while a SCA based business model can exist without TRA and the other exemption-based approaches. It 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 a transfer between the end user’s own accounts. 

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 10 seconds (max) transmission from when the sender submitting the payment, until the receiver gets the money through 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.

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

The extra element for all remote transactions is 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 by dedicated end-user hardware devices with a separate display and keypad, or 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’.

Okay 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 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 Okay Secure Mobile Platform.

Noncompliant payment service providers must refund any claimed fraud by the payment user within 24 hours, no questions asked. PSD2 foresees payers claiming full reimbursement from their PSP in cases of unauthorised payments if there was no SCA measure in place, and if the payer did not act fraudulently.

PSD2 RTS on SCA Article 38 states that the regulation shall apply from 14 September 2019.

However, paragraphs 3 and 5 of PSD2 RTS on SCA Article 30 says it will apply from 14 March 2019. 

With such uncertainly, it is important for PSPs to have available testing facilities, including support for connection and functional testing. This applies to authorised 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 authorisation to test their software and applications). 

Required to be made available no later than 6 months before the enforcement of PSD2 RTS on SCA, the testing facility should be available from 14 March 2019.