What counts as "possession"? Analyzing the EBA Opinion on SCA elements

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.

What counts as inherence?

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, these inherence elements are SCA compliant:

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 (or EMV 3DS) is not considered SCA compliant - as none of the data relates to biological and behavioural biometrics - but this may change in the future.

Despite this not being compliant for SCA, this data is critical for Transaction Risk Analysis (TRA) and enabling exemptions.

What counts as possession?

The EBA states that this does not need to be something physical – for example, it could be an app, provided that there are reliable means to confirm possession. This can be confirmed through a one-time password (OTP) or a push notification. A QR code could also be used as evidence of possession.

Printed card details don’t count as possession. But 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.

What counts as knowledge?

This is a non-exhaustive list of knowledge elements. It’s important to remember that the implementation approach will impact compliance.

Additional requirements for these elements

Dynamic linking

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.

Independence

The two elements must be independent of each other. One element cannot compromise the reliability of another.

Card reader eligibility

This scenario could constitute two elements in one – eg. in the typical use of a card reader, the PIN is first inserted to access the device, and then the OTP is generated.

Reusing elements

An element may be used twice within a session – for example to initiate a payment and perform another service that requires SCA eg. 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.

Are today’s widely-used methods compliant?

Today, some SCA-compliant elements are already in use:

• E-wallets constitute the knowledge and/or inherence element, as the device is bound to an app.
• OTP combined with a knowledge element like a PIN, or an inherence element like a fingerprint.
• Some card readers would also be considered compliant.

There are also some non-compliant methods which are widely used today:

• Card details which are printed in full, and used in conjunction with an SMS OTP or 3DS2 communication protocol.
• SMS OTP and dynamic card security codes used in conjunction with each other, as they are both possession elements.

Summary - check the guidelines carefully!

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.

Further reading

• Global Payments Report 2025 – free download
• Ravelin 3DS & SDKs
• Balancing conversion and fraud risk with 3D Secure
• 3D Secure: Developer notes
• Ravelin Insights: PSD2, SCA, 3DS