Strong Customer Authentication Under PSD3 and PSR: Key Discussions to Watch

1. Behavioral and Environmental Characteristics as Authentication Factors
   Regulators are considering whether behavioral and environmental biometrics can count as valid “inherence” factors for SCA. Data points like a user’s location, device or browser attributes, transaction timing, spending patterns, IP address, and other session info are already used in fraud detection models. Formally recognizing these signals as authentication elements under PSD3 would provide regulatory clarity and could enable more frictionless user experiences. The European Commission’s draft indicates in its recitals that inherence should account for such characteristics as part of transaction monitoring, and industry groups have urged making it explicit that these behavioral and environmental characteristics qualify as SCA elements (paymentseurope.eu). As technology evolves, non-physical biometrics (e.g. typing cadence or geolocation patterns) are proving capable of identifying individuals as reliably as physical attributes, so expanding the inherence category would acknowledge modern authentication methods.
   
   
2. Outcome-Based Approach and the Transaction Risk Analysis (TRA) Exemption
   There is momentum toward an outcome-based approach to authentication, where success is measured by actual fraud outcomes rather than just box-checking prescriptive rules. In practice, this means regulators may allow more flexibility (or additional SCA exemptions) when a Payment Service Provider (PSP) can demonstrate low fraud rates through robust risk-based controls. One centerpiece of this discussion is the Transaction Risk Analysis (TRA) exemption, which lets PSPs forego SCA for low-risk transactions. PSD3/PSR looks to reinforce the TRA mechanism, balancing security and user experience by trusting PSPs’ fraud models — but also shifting accountability onto PSPs to keep fraud levels demonstrably low. In other words, if a PSP’s risk engine maintains fraud below certain thresholds, it could bypass SCA more often, but it will bear responsibility if fraud rises. The European Banking Authority (EBA) is expected to issue guidelines refining the scope of TRA, requiring firms to monitor transactions with environmental and behavioral data points to ensure only genuinely low-risk payments skip SCA.
   
   
3. SCA Delegation and Outsourcing
   Who can perform SCA, and under what terms? PSD3 and PSR will likely clarify the conditions under which authentication can be delegated to third parties (such as wallet providers, merchant platforms, or other technical service providers) and when such delegation is considered outsourcing. The draft rules explicitly categorize a bank delegating SCA to a third party as an outsourcing arrangement, meaning all EBA Outsourcing Guidelines and oversight would apply. This move acknowledges that entities closest to the customer (e.g. e-commerce platforms or digital wallets) might handle the authentication step to streamline the user journey. Allowing Delegated Authentication could foster innovation in user-friendly security solutions. However, subjecting every instance to full outsourcing compliance creates a heavy burden. Industry advocates worry that requiring formal outsourcing agreements for all third-party SCA methods would increase complexity and cost, potentially stifling competition and excluding smaller fintech players. A nuanced approach is under debate: for example, only treating it as outsourcing when the bank/PSP truly relinquishes control over the authentication, while not over-regulating cases where the PSP still oversees the process. Clear rules on SCA delegation will be especially relevant for embedded finance and open banking, where the user journey often spans multiple providers.
   
   
4. Liability of Technical Service Providers and Scheme Operators
   Under PSD2, the allocation of liability in the authentication process has been something of a gray area, especially for parties like technical service providers (TSPs) and card scheme operators that facilitate SCA behind the scenes. PSD3/PSR discussions indicate more explicit liability provisions are coming. Notably, the current PSR draft introduces a new article assigning liability to TSPs and operators of payment schemes if they fail to provide necessary services to enable SCA. In other words, if an authentication breakdown occurs because a scheme’s or tech provider’s systems did not support SCA properly, they could be held financially responsible. This represents a shift toward shared accountability across all parties involved in an SCA transaction, aiming to incentivize cooperation on security. However, industry groups like Payments Europe have criticized the Parliament’s draft language as disproportionate, arguing it targets only two types of actors (schemes and TSPs) when many others are involved in the authentication chain over which those two have no direct control. They note that contracts already govern liability among participants in most cases, and that a blanket liability on schemes/TSPs might be unfair. Finding the right balance in liability distribution will be key to ensure every player (banks, merchants, schemes, tech providers) maintains strong security without discouraging cooperation or innovation.
   
   
5. Merchant-Initiated Transactions (MITs)
   Merchant-Initiated Transactions, such as subscription payments, installment billing, or other delayed charges initiated by the merchant, remain a complex corner of SCA compliance. In these scenarios, the payer isn’t present to authenticate when the transaction is executed, which under PSD2 put them outside the scope of SCA as long as the initial mandate was authenticated. PSD3 and PSR seem poised to provide clearer definitions and rules for MITs. The latest proposals explicitly define MITs in the legal text and clarify that SCA needs to be applied only at the setup of the mandate or agreement, not for each subsequent charge. This formalizes the common practice: for example, when a customer enrolls in a subscription or recurring payment, that first setup would require SCA, but the monthly or periodic charges can proceed without friction as MITs (provided they’ve been properly flagged and authorized). Regulators are discussing an expanded framework for identifying and handling MITs within SCA rules – including possibly a registration process or tagging mechanism so that these transactions are recognized by issuers. The goal is to ensure MITs are processed smoothly without unnecessary challenges, while still guarding against fraud. (Notably, PSD3 may introduce an eight-week unconditional refund right for consumers on MIT payments, aligning them somewhat with direct debit protections, though this is more about consumer rights than authentication.) Overall, clearer treatment of MITs under PSD3 should help both merchants and banks reduce fraud while minimizing user disruption.
   
   
6. Categories of SCA Factors – Two of a Kind?
   One striking change in the PSD3 draft is the possibility of using two authentication factors from the same category. Under PSD2, the law required SCA to comprise factors from at least two of the three categories (knowledge, possession, inherence) for security through diversity. PSD3’s current draft removes that requirement as long as the two elements are independent. This means, for instance, two “possession” factors (perhaps two separate devices or a device + app combination) or two “knowledge” factors (e.g. two different passwords or PINs) could theoretically satisfy SCA, whereas before that would not count. The rationale given by regulators is to improve accessibility and inclusivity – allowing combinations like a fingerprint and face scan (two inherence biometrics) or a token device and an SMS OTP (two possession factors) might offer convenience in certain cases. It could also help users who don’t have a smartphone by permitting two non-phone-based methods. However, this proposal is controversial. The EBA itself, in its opinion, has recommended sticking with the PSD2 rule (i.e. factors from two different categories) due to security concerns. Critics argue that two of the same type may weaken protection — for example, two passwords are only marginally better than one. If one factor is compromised, a similar second factor might be compromised in the same way, whereas two different factor types provide layered security. This debate is ongoing: the final PSD3/PSR text may still revert to requiring distinct categories, or it may embrace the new flexibility. In any case, if two-of-a-kind factors are allowed, they must be truly independent and non-correlated for the combination to be secure.
   
   
7. Fine-Tuning SCA Exemptions
   Beyond TRA, other SCA exemptions (like those for low-value payments, contactless transactions, trusted beneficiaries, etc.) are under the microscope in PSD3 discussions. Regulators recognize that the current thresholds and conditions — while effective for security — sometimes introduce friction that hurts conversion and customer experience. Industry feedback since PSD2’s rollout has highlighted pain points such as frequent declines of small purchases or abandonment of shopping carts when SCA triggers unnecessarily. The PSD3 process is likely to revisit and refine the exemption regime to strike a better balance between fraud prevention and user convenience. This could mean raising certain thresholds or adding new carve-outs for very low-risk scenarios. For example, Payments Europe has suggested raising the contactless payment cap from the current €50 (under PSD2) up to €250 per transaction, given the popularity and relatively low fraud on contactless card payments. They also recommend extending the existing exemption for unattended parking and transport terminals to include EV charging stations, reflecting new use cases. Other potential tweaks might involve how “trusted beneficiaries” are managed or adding exemptions for specific industries (Travel? In-flight payments are even mentioned as an example). The aim is to allow smoother customer journeys for low-value or routine transactions without compromising overall security. Any loosening of exemptions would likely be paired with proportionate liability rules – ensuring that if PSPs take advantage of higher limits or broader exemptions, they also shoulder responsibility for any fraud that results.
   
   
8. SCA for Mail Orders and Telephone Orders (MOTO)
   MOTO transactions – payments where the card details are provided via mail or phone – have traditionally been outside the scope of SCA. PSD2’s Regulatory Technical Standards effectively exempted MOTO by defining SCA as required only for “electronic” payment processes, and treating telephone or mail-initiated payments as non-electronic. This exemption exists largely because these channels cannot easily support the typical SCA process (you can’t input a texted OTP over a phone call, for instance). The downside is fraudsters have abused MOTO channels as a loophole. In the PSD3 discussions, regulators appear inclined to maintain the MOTO exemption but clarify it to prevent abuse. The current drafts explicitly state that the obligation to apply SCA only applies to the initiation of a transaction, not its execution. In practice, this means if a customer gives their card number over a telephone order, that initiation is considered offline (no SCA required), even if the merchant later processes it via an online system. PSD3 will likely encode this interpretation clearly: a MOTO transaction is treated as “non-electronic” when initiated via voice or mail, and thus SCA-exempt. There may, however, be guidance on risk-checks for MOTO transactions to mitigate fraud – e.g. requirements for fraud monitoring or confirmation mechanisms since these transactions won’t have SCA. The key point is to continue accommodating legitimate mail/phone orders (many of which serve elderly or offline customers) while not leaving the door open for fraud. Expect EBA or national regulators to possibly tighten how merchants must flag and handle MOTO transactions under the new framework.
   
   

SCA and Tokenization
Tokenization – replacing a card’s PAN (primary account number) with a surrogate “token” for security – has become a cornerstone of modern payments, from mobile wallets to card-on-file storage. One discussion point is whether initiating the tokenization of a payment credential should itself trigger SCA. The logic is that enrolling a card into a wallet or saving card details in a merchant’s system is a sensitive action, akin to adding a new payment instrument, and thus could be protected by strong authentication. The PSD3 proposals indeed touch on this: SCA would be required when the cardholder is actively involved in the tokenization process, such as when adding a card to Apple Pay/Google Pay or when saving card details for recurring use. In those cases, before the token is issued, the user might need to authenticate (for example, via 3-D Secure or bank app approval) to prove it’s really them requesting the token. This ensures that fraudsters can’t tokenize a stolen card without the owner’s knowledge. However, not every tokenization scenario is user-initiated (tokens can be issued server-to-server for security without user action), so the rules will likely specify it’s only when the customer is enrolling or replacing a card that SCA must kick in. Clarifying SCA for tokenization will close a potential gap in the ecosystem and further secure the card-on-file process, making sure that a tokenized credential is as trustworthy as a fully SCA-authenticated

If the final PSD3 directive and PSR regulation texts are adopted by late 2025, we can expect major changes to start taking effect over the subsequent years. The PSR, being directly applicable to EU law, could come into force in all Member States as early as 2026. PSD3, on the other hand, will require transposition into national laws. Assuming a typical timeline, that means a transposition deadline around 2027 for EU countries to integrate PSD3 provisions locally. During this period, the European Banking Authority will be busy drafting new Regulatory Technical Standards and guidelines — for example, on dynamic linking and on the refined SCA requirements and exemptions.

At Okay, we’re particularly interested in how the EBA will address dynamic linking in its guidance. Dynamic linking is a cornerstone of SCA that ensures the authentication code is tied to the specific transaction amount and payee, thwarting man-in-the-middle attacks. In practice, we’ve seen some fragmented implementations and edge cases (such as scenarios where the final amount can change, like grocery deliveries or fuel pumps). Clear and practical guidance from the EBA on dynamic linking under PSD3 will be crucial. A flexible approach may be needed to accommodate legitimate cases where the exact amount isn’t known at the time of authentication, as long as the customer is made aware and consents to potential variances. Ensuring consistency here will help the industry avoid confusion and keep user protections robust.

Overall, the evolving SCA provisions in PSD3/PSR aim to refine the balance between security and convenience. All stakeholders — banks, fintechs, merchants, and payment processors — should keep a close eye on these discussions. The final rules (and subsequent EBA standards) will shape how Europeans authenticate payments for years to come, hopefully making payments both safer and smoother for everyone involved. By planning ahead and engaging with regulators’ guidance, the industry can adapt to these changes with minimal disruption and even turn them into a competitive advantage in offering user-friendly yet secure payment experiences.