Blog / 3DS & SCA, Ravelin University, Payments & payment fraud
The EBA is strict about what’s considered compliant for inherence, possession and knowledge under SCA. We look closer at the new requirements for each element and how today’s widely used authentication methods compare.
17 February 2020
The Strong Customer Authentication (SCA) regulatory technical standards (RTS) require two of three elements to be met in order for authentication to be successful.
These three elements are inherence, possession, and knowledge. Or, in other words: something the user is, something they have, and something they know.
However, the EBA Opinion Paper is strict about what actually counts as inherence, possession, and knowledge under SCA. In this article, we take a closer look at the new requirements for each element and how this compares to widely-used methods today.
Inherence is defined as "something the user is". Article 8 of the technical standards refers to authentication elements that would be read by devices and software.
Depending on the implementation, the below inherence elements are SCA compliant. They include some biometrics and some other elements.
| Inherence element | SCA compliant? |
|---|---|
| Fingerprint scanning | Yes ✅ |
| Voice recognition | Yes ✅ |
| Vein recognition | Yes ✅ |
| Hand & face geometry | Yes ✅ |
| Retina & iris scanning | Yes ✅ |
| Keystroke dynamics | Yes ✅ |
| Heart rate or other body movement pattern (e.g. from wearables) | Yes ✅ |
| Information transmitted using communication protocol e.g. 3DS | No ❌ |
| Memorized swipe path | No ❌ |
If a user memorizes a swiping path on their device, this does not count as an inherence element, but it does count as a knowledge element.
It’s important to note that user information sent via 3D Secure 2 (EMV 3DS) is not considered SCA compliant, as none of the data relates to biological and behavioral biometrics – but this may change in the future.
Despite this not being compliant for SCA, this 3DS data is critical for Transaction Risk Analysis (TRA) and enabling exemptions.
The EBA states that "possession" does not need to be something physical. For example, it could be an app, provided that there are reliable means to confirm possession.
Possession can be confirmed through a one-time password (OTP) or a push notification. A QR code can also be used as evidence of possession.
Printed card details don’t count as possession. However, dynamic card security codes can count, as long as they are changed regularly and are not printed on the card itself. This applies to some virtual cards too.
| Possession element | SCA compliant? |
|---|---|
| Possession of a device evidenced by an OTP generated by, or received on, this 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 (e.g. 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 (e.g. OTP list) | No ❌ |
Below is a non-exhaustive list of knowledge elements for purposes of SCA.
It’s important to remember that the implementation approach will also impact compliance.
| Knowledge element | SCA compliant? |
|---|---|
| Password | Yes ✅ |
| PIN | Yes ✅ |
| Knowledge-based challenge questions | Yes ✅ |
| Passphrase | Yes ✅ |
| Memorized swiping path | Yes ✅ |
| Email address or username | 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 ❌ |
It's important to note that there are additional requirements for these elements, including dynamic linking and independence. More specifically:
There must be at least two elements used to meet SCA compliance, and the elements must dynamically link the transaction to an amount and a payee specified by the payer when initiating the transaction.
This means that at the time of the transaction, the value of the transaction and the identity of the recipient must be displayed.
Dynamic linking is possible through the generation of authentication codes. There are strict security rules explained in more detail here.
The two elements must be independent of each other.
One element cannot compromise the reliability of another.
This scenario could constitute two elements in one. For example, in the typical use of a card reader, the PIN is first inserted to access the device, and then the OTP is generated.
An element may be used twice within a session. For example, to initiate a payment and perform another service that requires SCA e.g. to access an account.
A possible scenario is when a user performs SCA to save a new card to an account and then must also perform SCA to set up a payment. In this case, the device could be used as the possession element for both SCA instances.
For a payment provider, another example could be if a user accesses their account using a static password (knowledge) and OTP (possession) and then immediately initiates a payment.
Today, some SCA-compliant elements are already in use:
There are also some non-compliant methods which are widely used today:
The EBA is strict about what counts for each element behind SCA.
Possession must be something physical that the user has. A combination of QR codes, card readers or OTPs might be popular for those wishing to remain compliant.
Knowledge is about what the user knows – passcodes and PINs make this more familiar to everyday users. These are just two possible examples of something the user knows. Memorized swiping paths count as knowledge, not inherence.
The user data sent via 3DS currently does not count as the inherence element (something the user is). This may have come as a surprise to many businesses who believed the enhanced version of 3DS and its biometric capabilities provided salvation for those struggling to develop compliant solutions.
This highlights how important it is to review guidelines carefully to ensure your authentication strategy is not taken by surprise.
Exclusive data: authentication rates, frictionless rates, SCA mandates and more.
Catherine Jones Product Director
