Blog article
See all stories »

'Authentication code' and the future of payment transactions at the point of sale.

The Payment Services Directive (PSD2), introduces new rules on how the payment services are going to be governed. Strong Consumer Authentication (SCA) implements new standards where (Article 97) the payer: (a) accesses its payment account online; (b) initiates an electronic payment transaction; (c) carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.

SCA is based (Article 4, RTS) on two or more elements categorized as knowledge, possession, and inherence and shall result in the generation of an authentication code. However, the PSD2 or the supplementary report on regulatory technical standards (RTS) regarding SCA does not explain how the authentication must be used or the limitations and scope of the authentication code.

Let’s first look at what the PSD2 says. Recital 96 in the PSD2 equates the authentication code to a one-time password, and it is the only mention of the term ‘authentication code’ in the whole of the Second Payment Services Directive. Whereas, the FAQ that accompanies the PSD2 gives an example that a possession element for the SCA might be a device that generates the authentication code.

The inconsistencies in the meaning of the authentication code are rather obvious. The FAQ states that the ‘authentication code’ is used to confirm the payer holds the ‘possession element’ for the SCA. Article 4 of the RTS gives us the impression that the confirmation of the two elements would generate the authentication code, which then would be used to initiate the payment.

For now, let us assume that the authentication code is a password that is generated once the two elements have been confirmed. Then it is unclear how the authentication code confirms the initiation of the payment whether it would be, as a recital 96 states, as a one-time password, or whether it would be a code that would be sent to the payment initiator without the payer manually entering the code. The latter view has been held by companies like VISA Europe, which have added an ending to Article 4 of the RTS. According to them, ‘two or more factors based on possession, knowledge or inherence shall result in the generation of an “authentication code” to the payer’s PSP that is only accepted once by the PSP for the same payment services user’.[1]

The use of authentication becomes interesting when you think about the practical aspect of electronic payments at the point of sale or face-to-face situations. The SCA, according to the PSD2 Article 97, applies to all electronic payments. The only exemption to the SCA at the ‘point of sale’ transactions applies to the contactless payments and there is no exemption to the ‘chip and pin’ payment method for the application of SCA. Even though, the ‘chip and pin’ method might satisfy the two-element requirement (the electronic bank card being the ‘possession element’ and the pin being the ‘knowledge element’), with the RTS supplementing the PSD2 there will be the need of generating the authentication code. It is difficult to imagine a situation where in addition to inserting your card to the terminal and putting your PIN in you will also receive a message with an authentication code that you will have to enter for the payment service provider. Such impracticality of the chip and pin technology is redundant today.

Why are the authentication code and its use so unclear? Visa, amongst others, believes that in order to preserve innovation and respect the principle of technological neutrality, the RTS should not set an exhaustive list of features for the “authentication code”. The principle that is reiterated time and time again in the final draft of the RTS.

The ‘final draft of the RTS’ is the place where the final answer is found. The answer to the question 272 part 4 is set out as ‘The EBA is of the view that chip and PIN transactions are not non-compliant with SCA provided that they are of DDA standard (Dynamic Data Authentication) or higher. It is, however, up to the providers and issuers to assess whether or not their systems comply with PSD2 as well as the RTS requirements.’ Even though the answer, like everything else, does not use determinative language, tells us that ‘chip and pin’ may remain a viable option for the future ‘point of sale’ transactions and that the authentication code is sent to the payer’s PSP once the payer passes the two-factor authentication.

However, it is worth pointing out that the PSD2 practically eliminates the use of magnetic stripe bank cards as a payment mechanism at the point of sale situations.

 

[1] https://eba.europa.eu/regulation-and-policy/payment-services-and-electronic-money/regulatory-technical-standards-on-strong-customer-authentication-and-secure-communication-under-psd2?p_p_auth=aQFQD6R4&p_p_id=169&p_p_lifecycle=0&p_p_state=maximized&p_p_col_id=column-2&p_p_col_pos=1&p_p_col_count=2&_169_struts_action=%2Fdynamic_data_list_display%2Fview_record&_169_recordId=1627603

 

8225

Comments: (3)

A Finextra member
A Finextra member 27 March, 2019, 07:03Be the first to give this comment the thumbs up 0 likes

Thanks for writing this, Tautvydas. 

It sounds like an OTP is the only way of fulfilling SCA based on what you've written. Is this right?

I understood it as 2FA, with OTP being just ONE possible option, even via SMS, which is the next worst thing after just a password. 

OTP would fulfill a knowledge-based factor, but it's just one way. 

I fear the SCA is directing banks to put the equivalent of a second pad lock on the door, because people keep cutting off the first. 

Tautvydas Medziukevicius
Tautvydas Medziukevicius - Swiipe - Copenhagen 28 March, 2019, 13:31Be the first to give this comment the thumbs up 0 likes

My understanding and the interpretation of the current legal framework on this matter is that there is more than one way of fulfilling SCA. What is certain from the law is that there must be two different and independent elements for the initial authentication stage. The initial authentication stage should produce an authentication code. The tricky part is how you put that authentication code in to use as it is not clear from the law. It is unclear whether the consumer must put in the authentication code himself or whether the payment initiator gets the code and lets the payment to proceed. If it is the first option, then OTP would be the only way around, once the two elements are confirmed. But if it is the second option then we can use the existing method of chip and pin and we do not need the OTP. But nevertheless, OTP could replace the pin code in the second scenario.

I believe it is the second scenario that will be applied, and thus the consumers will not need to insert the authentication code.

Yes, you are right in saying OTP can be one of the elements, but it would be the ‘possession’ element and not the ‘knowledge’ based element. A pin or multi-use passwords are knowledge-based elements because it is something you and only you know. OTP is based on the devices you have, and you will not know the one-use password if you don’t have the laptop or the phone, therefore it is a ‘possession’ based element.

If it is the first scenario, then I agree, it does not make sense to put another security layer on chip and pin type of transactions which are considered safe already.

A Finextra member
A Finextra member 28 March, 2019, 13:37Be the first to give this comment the thumbs up 0 likes

Thanks for your thorough response.

Like you said, "you will not KNOW the one-use password if you don’t have the laptop or the phone". Just because you don't know it for long, doesn't make it any less a piece of knowledge you will use in the operation. I know there is debate on this, certainly when it comes via SMS, as it's not the fact you own the phone, or even the SIM card; it's the fact you happen to be, at that time, at the end of a channel, which the code is sent on. That channel can be changed by someone else.

Either way, I have a few concerns regarding what is acceptable under SCA, and your article has worried me further if OTPs are being pushed on banks, and not just being allowed as one method of (poor) authentication.

Tautvydas Medziukevicius

Tautvydas Medziukevicius

Legal Counsel

Swiipe

Member since

14 Mar 2019

Location

Copenhagen

Blog posts

2

Comments

3

This post is from a series of posts in the group:

Fintech

Fintech discussions and conversations around the development of fintech.


See all

Now hiring