Principles for the implementation of strong customer authentication
Principles for the implementation of strong customer authentication
Over recent years, there have been significant developments in Israel’s payment systems leading to the creation of diverse, innovative methods of payment. However, the benefits of these advanced payment methods also carry with them risks to which both customers and merchants may be exposed, such as fraud, identity theft, counterfeiting, abuse, etc. To mitigate these risks and enhance competition and innovation, clear standards and principles must be set regarding how to authenticate the consumer’s identity with a strong degree of certainty.
The principles of strong customer authentication (SCA) are based on the process for SCA defined by the European Union, where the implementation of SCA is based on two or more of the following categories:
- Knowledge (Something You Know) - information only the user knows.
- Possession (Something You Have) - something only the user possesses. Possession refers not only to physical possession, but also to non-physical possession.
- Inherence - (Something You Are) - this category includes biological, behavioral and biometric features - something the user is.
In other words, to conduct SCA the user must be identified according to 2 or more elements, where each element is from a different category. These elements must also be independent, so that the breach of one does not compromise the reliability of the others and confidentiality of the data is protected.
Following are the elements in each category that may be considered an SCA-compliant item:
Knowledge - Something You Know:
Number |
Element |
SCA compliant item |
1 |
Password |
Yes |
2 |
PIN |
Yes |
3 |
Memorized swiping path |
Yes |
4 |
OTP |
Yes |
5 |
Email address |
No |
6 |
Username |
No |
7 |
Card details (printed on the card) |
No |
8 |
I.D. number |
No |
- Implementation of these elements should include measures to reduce their exposure to unauthorized entities.
Possession - Something You Have:
Number |
Element |
SCA compliant item |
1 |
Possession of a device evidenced by a One-Time Password (OTP) generated by or received on a device |
Yes |
2 |
Possession of a device evidenced by a signature generated by a device (hardware or software token) |
Yes |
3 |
Possession of a device or card evidenced through a QR code |
Yes |
4 |
App or browser with possession evidenced by device binding |
Yes |
5 |
Payment card with possession evidenced through the Point of Sale. |
Yes |
6 |
Payment card with possession evidenced by a dynamic card security code |
Yes |
7 |
Email address evidenced by a One-Time Password |
Yes |
8 |
Landline with possession evidenced by a One-Time Password |
Yes |
9 |
App installed on the device |
No |
10 |
Payment card with possession evidenced by card details (printed on the card) |
No |
11 |
Payment card with possession evidenced by any other printed element |
No |
- Implementation of these elements should include measures to prevent unauthorized use of or the ability to duplicate an element.
Inherence (Something You Are):
Number |
Element |
SCA compliant item |
1 |
Fingerprint scanning |
Yes |
2 |
Voice recognition |
Yes |
3 |
Hand or face geometry |
Yes |
4 |
Retina scanning |
Yes |
5 |
Keystroke dynamics |
Yes |
6 |
Heart rate or other body movement pattern |
Yes |
7 |
The angle at which the device is held |
No |
8 |
Information transmitted using a communication protocol |
No |
9 |
Memorized swiping path |
No |
- These elements must be implemented so as to make it unlikely that an unauthorized entity will be verified as the payer.
These rules and elements, reflecting the present situation, are possible elements that may be used for SCA and all payment service providers will be able to choose the elements relevant for them (based on their risk management practices). This in accordance with the principle that at least 2 or more of the 3 categories must be used.
These rules and elements are not a closed list and may be updated from time to time, in line with changes in technology, changes in the types of fraud and changes in market requirements. Consequently:
- An element used for authentication in one category cannot be used as an element in another. For example, OTP may be considered a knowledge or possession element but not both in the same transaction.
- Two elements may be used in the authentication process on the same device on which the transaction began. In other words, there is no obligation to use two different devices to start and finish the process.
- The authentication processes do not have to be exposed to the payer and may take place “behind the scenes”, provided that the transaction is recorded as a transaction performed under SCA.
3-D Secure protocol
3-D Secure (3DS) is an e-commerce authentication protocol that provides an additional layer of customer authentication enabling the secure processing of payment transactions in real time The protocol facilitates the exchange of data between the issuer, the merchant, and where necessary, also the consumer, so as to confirm that the transaction was initiated by the account’s lawful owner.
Based on the profile and risk management of each issuer, 3-D Secure technology supports the possibility of conducting an SCA process of the payer that is compliant with the standards set by the EBA (Strong Customer Authentication).
3DS Version 2.2 and higher is a new generation of the protocol which supports this process and covers a range of SCA parameters and methods, e.g.: location of the user performing the transaction, nature of previous transactions performed by the user, amounts paid in previous transactions, type of currency used, specific information about the device from which the transaction was made, information about the browser, including IP address, and more. After considering the weight of the data, the protocol assesses the risk in the transaction and accordingly it can ask the payer for additional authentication details and processes (e.g.: OTP) in order to verify its identity. In a 3DS authentication process, the authentication message will be dynamic so that the amount of the transaction and the merchant are visible to the payer.
These processes in the protocol can in fact identify the payer and authenticate his identity, in the background, without the payer being aware that authentication is being carried out (for example: identity of the specific device from which the payment is being made and that the payer has accessed the device by means of a code or other biometric identification).
Transactions authenticated by means of 3-D Secure protocol Version 2.2 and above can be considered transactions performed under an SCA process of the payer, It is emphasized that implementation of the mechanism requires the implementation of SCA compliant mechanisms, i.e. the use of at least two elements from different groups, according to generally accepted practice worldwide.
It is stipulated that this agreements between the market participants and that the publication of these principles does not indicate the position of the participants’ regulators, including the Banking Supervision Department, nor is it intended to compromise or limit their oversight and enforcement powers.
This information will be updated from time to time in line with changes and developments in this sector.
The information on this page is correct to January 3, 2023