#PSD2 #PSD3 #PSR #EBA #SCA #Knowledge #Possesion #Inherence #PaymentsCompliance #FintechRegulation
In the EU, to enhance payment security and reduce fraud, multi-factor authentication (MFA) under the Strong Customer Authentication (SCA) requirements of the Second Payment Services Directive (PSD2) is enforced. It requires payment service providers (PSPs) to implement the authentication mechanism for payment service users (PSUs) combining at least two out of three elements from the following categories:
- Knowledge
- Possession
- Inherence
To better understand these categories, I found the European Banking Authority’s (EBA) Opinion and Q&As particularly helpful, and I quote or paraphrase their explanations here.
What Does SCA Look Like in Real Life?
The term might look unfamiliar. Let’s take ING’s mobile banking app as an example. The app first requires binding to the user’s mobile phone (possession). At login, the user must provide either a password (knowledge) or use facial recognition (inherence). When initiating a transaction, the app again relies on the device (possession) and requires a separate transaction PIN (knowledge), distinct from the login password.
A Closer Look at the Three SCA Elements
Knowledge – Something only the user knows
To qualify as knowledge, the information should be secretive to PSU, which means it is not easily known by third party. PSPs are further required to have mitigation measures (e.g., the communication sessions are protected against the capture of authentication data) in place in order to prevent the disclosure to unauthorised parties.
The following elements could constitute a knowledge element: a password, a PIN, knowledge-based responses to challenges or questions, a passphrase and a memorised swiping.
Possession – Something only the user has
Possession includes both physical possession and something that is not physical (e.g, an app).
- For a device (physical possession) to be used as a possession element, generation or receipt of a dynamic validation element on the device as a proof shall be enabled. For example,one-time password (OTP) received via text message or generated via software installed.
- For mobile apps, similarly, web browsers or the exchange of (public and private) keys, to be used as a possession, it shall contain a device binding process that ensures a unique connection between the PSU’s app, web browsers, or the exchange of (public and private) keys, and device.
Inherence – Something the user is
Inherence includes biological and behavioural biometric of the user. It relates to physical properties of body parts, physiological characteristics and behavioural processes created by the body, and any combination of these. For example, inherence may include retina and iris scanning, fingerprint scanning, face and hand geometry (identifying the shape of the user’s face/hand), the angle at which the PSU holds the device.
Are These Categories Changing under PSD3 and PSR?
Although the proposed PSD3 and the new Payment Services Regulation (PSR) bring structural and supervisory changes, the definitions of knowledge, possession, and inherence under SCA remain unchanged. This means compliance professionals can continue to rely on the current regulatory interpretations considering these 3 categories of elements.
More Real-World Examples
The following three tables released and validated by EBA are quite useful to verify if the considered thing or method can be classified into one of categories:
Table 1 — Non-exhaustive list of possible inherence elements
|
Element |
Compliant with SCA? |
|
Fingerprint scanning |
Yes |
|
Voice recognition |
Yes |
|
Vein recognition |
Yes |
|
Hand and face geometry |
Yes |
|
Retina and iris scanning |
Yes |
|
Keystroke dynamics |
Yes |
|
Heart rate or other body movement pattern identifying that the PSU is the PSU (e.g. for wearable devices) |
Yes |
|
The angle at which the device is held |
Yes |
|
Information transmitted using a communication protocol, such as EMV® 3-D Secure |
No |
|
Memorised swiping path |
No |
Table 2 — Non-exhaustive list of possible possession elements
|
Element |
Compliant with SCA? |
|
Possession of a device evidenced by an OTP generated by, or received on, a device (hardware or software token generator, SMS OTP) |
Yes |
|
Possession of a device evidenced by a signature generated by a device (hardware or software token) |
Yes |
|
Card or device evidenced through a QR code (or photo TAN) scanned from an external device |
Yes |
|
App or browser with possession evidenced by device binding — such as through a security chip embedded into a device or private key linking an app to a device, or the registration of the web browser linking a browser to a device |
Yes |
|
Card evidenced by a card reader |
Yes |
|
Card with possession evidenced by a dynamic card security code |
Yes |
|
App installed on the device |
No |
|
Card with possession evidenced by card details (printed on the card) |
No |
|
Card with possession evidenced by a printed element (such as an OTP list) |
No |
Table 3 — Non-exhaustive list of possible knowledge elements
|
Element |
Compliant with SCA? |
| Password |
Yes |
| PIN |
Yes |
| Knowledge-based challenge questions |
Yes |
| Passphras |
Yes |
| Memorised swiping path |
Yes |
| Email address or user name |
No |
| Card details (printed on the card) |
No |
|
OTP generated by, or received on, a device (hardware or software token generator, SMS OTP) |
No |
| Printed matrix card or OTP list |
No |