--- title: "What counts as \"possession\"? Analyzing the EBA Opinion on SCA elements" date: 2020-02-17T11:15:00+00:00 author: Catherine Jones canonical_url: "https://www.ravelin.com/blog/analyzing-the-eba-opinion-on-sca-elements" section: Blog --- Blog /[3DS & SCA](/resources?search=&category%5B0%5D=134550#resourceContainer "Go to 3DS & SCA"), [Ravelin University](/resources?search=&category%5B0%5D=257999#resourceContainer "Go to Ravelin University"), [Payments & payment fraud](/resources?search=&category%5B0%5D=189241#resourceContainer "Go to Payments & payment fraud") # What counts as "possession"? Analyzing the EBA Opinion on SCA elements 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 ![What counts as "possession"? Analyzing the EBA Opinion on SCA elements](https://storage.googleapis.com/ravelin-website-assets-production/assets/images/_blogSmall/71597/SCA-elements-blog.webp) The [Strong Customer Authentication](https://www.ravelin.com/insights/ultimate-guide-psd2-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](https://eba.europa.eu/eba-publishes-an-opinion-on-the-elements-of-strong-customer-authentication-under-psd2) 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, the below inherence elements are SCA compliant. They include some biometrics and some other elements. ### SCA-compliant inherence elements Inherence elementSCA compliant?Fingerprint scanningYes ✅Voice recognitionYes ✅Vein recognitionYes ✅Hand & face geometryYes ✅Retina & iris scanningYes ✅Keystroke dynamicsYes ✅Heart rate or other body movement pattern (e.g. from wearables)Yes ✅Information transmitted using communication protocol e.g. 3DSNo ❌Memorized swipe pathNo ❌ 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)](https://developer.ravelin.com/psp/guides/3d-secure/overview/) 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](https://www.ravelin.com/blog/sca-transaction-optimization-guide-exemptions)**. ## What counts as possession? 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. ### SCA-compliant possession elements Possession elementSCA 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 deviceYes ✅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 readerYes ✅Card with possession evidenced by a dynamic card security codeYes ✅App installed on the deviceNo ❌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 ❌ ## What counts as knowledge? 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. ### SCA-compliant knowledge elements Knowledge elementSCA compliant?PasswordYes ✅PINYes ✅Knowledge-based challenge questionsYes ✅PassphraseYes ✅Memorized swiping pathYes ✅Email address or usernameNo ❌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 listNo ❌ ## Additional requirements for these elements It's important to note that there are additional requirements for these elements, including dynamic linking and independence. More specifically: ### **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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2018.069.01.0023.01.ENG&toc=OJ:L:2018:069:TOC). ### **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. 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. ### **Reusing elements** 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. ## Are today’s widely-used methods compliant? Today, some SCA-compliant elements are already in use: - [E-wallets](https://www.ravelin.com/blog/what-does-fraud-look-like-on-digital-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 ## 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. ![Ravelin Logo](https://storage.googleapis.com/ravelin-website-assets-production/assets/images/ravelin-symbol-logo-transparent.webp) ## Global 3D Secure map Exclusive data: authentication rates, frictionless rates, SCA mandates and more. [Browse the map ](https://www.ravelin.com/3ds-global-payment-authentication-map-sca) ## Further reading - [Global Payments Report 2025 – free download](https://pages.ravelin.com/payments-report-2025) - [Ravelin 3DS & SDKs](https://www.ravelin.com/old-pages-and-duplicates/solutions-o/3ds-product-3d-secure-server-sdks) - [Balancing conversion and fraud risk with 3D Secure](https://www.ravelin.com/blog/balancing-conversion-and-fraud-risk-with-3-d-secure) - [3D Secure: Developer notes](https://developer.ravelin.com/psp/guides/3d-secure/overview/) - [Ravelin Insights: PSD2, SCA, 3DS](https://www.ravelin.com/insights/ultimate-guide-psd2-strong-customer-authentication) ## Author ![Catherine Jones](https://storage.googleapis.com/ravelin-website-assets-production/assets/images/_avatarSmall/76597/kit-photo.webp) Catherine JonesProduct Director Product Director Catherine has been with Ravelin for over six years and likes to call herself a payments and authentication nerd. Across… [More from this author](https://www.ravelin.com/author/catherine-jones) ## Related content [Blog / Payments & payment fraud ### Card payment liability shift – everything you need to know to reduce chargeback burden The knowledge you need to make the most of liability shifts and reap the benefits for your company – including saving money on chargebacks. ![Freddie burgess](https://storage.googleapis.com/ravelin-website-assets-production/assets/images/_33x33_crop_center-center_none_ns/281707/freddie-burgess.webp)Freddie Burgess,Senior Product Support Analyst](https://www.ravelin.com/blog/card-payment-liability-shift-for-chargebacks) [Blog / Fraud analytics ### Refund abuse KPIs: How to measure and reduce refund fraud rates What you need to know to assess and quantify refund abuse – as well as to measure whether your refund abuse solution and strategy are delivering results. ![Can](https://storage.googleapis.com/ravelin-website-assets-production/assets/images/_33x33_crop_center-center_none_ns/280078/can.webp)Can Colak,Senior Product Manager](https://www.ravelin.com/blog/how-to-measure-refund-abuse-kpis) [Blog / Press release ### Driven by AI, customers now rival criminals for ecommerce fraud, say merchants Global ecommerce fraud enters a new phase as losses continue to climb. Merchants now view criminals and their own customers as presenting a comparable risk, and there's a gap in AI adoption. ![Ravelin Symbol Blue 1](https://storage.googleapis.com/ravelin-website-assets-production/assets/images/_33x33_crop_center-center_none_ns/187712/Ravelin-Symbol-Blue-1.webp)Ravelin Technology](https://www.ravelin.com/blog/ravelin-fraud-survey-2026-press-release)