PSD2 Strong Customer Authentication for EU Platforms

Why platform operators need a stricter PSD2 SCA operating model now#

Platform operators need a stricter PSD2 SCA operating model now because failures show up first as declined payments, abandoned checkouts, support load, and missed revenue, not just as legal findings. If you cannot show who owns each SCA decision and how it was implemented, you have a payments control gap. Teams tracking that fallout should compare SCA-specific friction against a payment decline benchmark view so they do not treat every approval-rate problem as the same issue.

PSD2, Directive (EU) 2015/2366, sets the legal base, and the detailed SCA rules sit in the RTS under Commission Delegated Regulation (EU) 2018/389. Operationally, Article 97 is the trigger point: SCA applies when a payer accesses an account online, initiates an electronic payment, or performs certain risky remote actions. Where SCA applies, authentication must use at least two independent elements across knowledge, possession, and inherence.

Even though PSD2 is framed for payment service providers, platform exposure is direct. Banks must decline transactions that require SCA but do not meet the criteria, and issuing banks must refuse non-compliant transactions. For in-scope EU card payment failures, you should be able to confirm whether SCA was required, whether 3DS2 was attempted, and who owns remediation.

The tradeoff is real. SCA has reduced fraud, but it can also reduce legitimate checkout completion. Stripe cites Visa's estimate of an 11% conversion drop for SCA-compliant transactions in high-friction flows, while the joint EBA-ECB fraud report points to lower fraud levels after SCA. That is why this cannot sit with compliance alone. It takes coordinated execution across compliance, payments, product, and operations.

Lower fraud rates are not a reason to relax controls. EBA and ECB report an EEA payment fraud rate around 0.002% by value in 2024, but total fraud still rose to €4.2 billion from €3.5 billion in 2023, and payer-manipulation fraud is increasing. 3DS2 remains the main method for authenticating online card payments and meeting SCA requirements, but it is not a one-time fix.

A stricter model starts with ownership and evidence: configuration records, approval history for payment-flow changes, and decline logs that separate likely SCA failures from broader authorization issues. The rest of this article focuses on three outcomes:

• clear control ownership across internal teams and payment processors
• a practical reporting checklist for ongoing monitoring
• escalation triggers for interpretation issues versus authentication or processor-path failures

Define the scope before you change payment flows#

Start with the legal trigger, not the checkout design.

PSD2 is the EU legal framework for payment services, and Article 97 is the operational trigger for when SCA must be applied, including payment initiation. For your team, scope starts by mapping each payer action in the journey to an Article 97 trigger, then assigning a processor configuration owner and an evidence trail.

Strong Customer Authentication is not a generic "add 3DS everywhere" rule. It requires at least two independent elements across knowledge, possession, and inherence, and remote electronic payments must include dynamic linking to the specific amount and payee. In practice, you should be able to show that the payment path supported SCA, the authentication attempt was recorded, and the transaction data matched what the customer saw.

For the EU baseline, use PSD2 and the RTS in Commission Delegated Regulation (EU) 2018/389. They make clear that recurring transactions are not blanket-exempt: SCA is required when a payer creates, amends, or first initiates a series. Country counsel is still required where national transposition or enforcement practice affects interpretation, because directives are implemented through national law and supervised by national competent authorities.

Before shipping payment-flow changes, separate scope by payment event:

• One-time card payments: map each payment initiation path against Article 97 triggers.
• Recurring transactions: treat creation, amendment, and first initiation as explicit SCA checkpoints under the RTS.
• Subscription payment models: map each charge event, not just the plan label, because the commercial model and the legal payment event are not the same.

Make the non-assumptions explicit. Do not assume every subscription renewal is automatically outside SCA, do not assume only fully intra-EU flows matter, and do not apply SCA controls to every account action unless the payer action actually triggers SCA under PSD2.

Map where SCA actually breaks in your payment journey#

If you label every failed payment as an SCA issue, you will fix the wrong thing.

Map the journey as four separate stages, and only call something an SCA issue when you can show exactly where it broke: checkout, issuer authentication, authorization, or settlement.

Article 97 tells you when SCA is required, but operational losses usually happen at stage handoffs. In a typical 3DS2 card flow, the customer enters card details, the issuer assesses the transaction, and the issuer may require extra authentication through its 3DS Access Control Server, or ACS. Stripe's 3D Secure authentication flow is a useful reference for that handoff, and many teams pair it with a payments orchestration multi-gateway strategy so issuer, acquirer, and retry-path failures do not get lumped together.

Trace the journey stage by stage#

Use a journey map that shows the event, decision point, expected evidence, and owner for remediation.

The handoff into ACS and the result returned is usually the checkpoint that matters most. If logs only show "3DS attempted" or "payment failed," you cannot tell whether the problem was customer abandonment, issuer-side failure, or a post-auth decline.

Separate three failure modes that look similar in dashboards#

Challenge drop-off is commonly misread. Redirect-based challenge flows can lose conversion because of technical redirect errors or shopper abandonment, so check challenge success rate before you assume fraud rules or exemption logic are the cause.

Issuer mismatch should sit in a separate bucket. A cardholder can be enrolled in 3DS while the issuer does not support the path, so failed authentication is not always an integration defect on your side.

Communication and timeout issues also need their own bucket. Payment lifecycle reporting includes communication-error statuses, and settlement is a distinct downstream stage after authorization and clearing. If analysis stops at checkout logs, post-auth downstream failures are easy to miss.

Add one evidence box before you change anything#

Known vs unknown

Known - You can identify challenged payments and completed challenges. - You can separate authenticated transactions from issuer authorization declines.

Unknown - Whether drop-off happened before redirect, during challenge, or after return to merchant. - Whether issuer capability or issuer decisioning caused a failed 3DS2 path.

If the unknown column is longer than the known column, fix the evidence trail before you tune flow copy or processor settings.

Set ownership and escalation before the next incident#

Set ownership before the next incident, not during it.

If Article 97 scope, RTS exception handling, or Article 96 escalation has no clear owner, failure response slows while risk grows.

For regulated payment activity, anchor this in PSD2 Article 95. You need a formal operational and security risk framework with defined control mechanisms, and incident-reporting responsibilities should sit in your general operational and security policy, not in informal notes. Your matrix should identify owner, evidence, review cadence, and escalation path.

Split legal questions from processor questions early#

Use one decision rule.

If the issue is rule interpretation, escalate to Legal or Compliance first. That includes whether SCA was required, whether an exemption was valid, whether an RTS exception was documented correctly, or whether a major incident may trigger authority reporting.

If the issue is in the authentication path, escalate to Processor or Product first. That includes ACS redirect failures, timeout clusters, issuer-path mismatches, or post-auth decline patterns that look operational rather than interpretive.

This split avoids a common mistake: treating processor optimization as a substitute for legal accountability. Processor and wallet involvement does not automatically transfer core SCA responsibility.

Keep one evidence pack ready#

Your minimum incident pack should include:

• incident log with dates, affected flow, severity, owner, and decision timeline
• approval history for exemptions, overrides, and remediation decisions
• exception decisions mapped to the RTS basis and recorded risk factors

If you cannot show why an exception was approved, treat that as a control gap and move the flow to full authentication until review. Also verify incident procedures against the post-17 January 2025 regime, because the PSD2 major-incident guideline set was repealed due to DORA harmonisation.

Choose the right authentication and payment path by scenario#

Choose the path by failure pattern, not by adding rails by default.

Validate SCA and card-auth controls first, then add alternatives only where they solve a specific, repeated issue.

Start with cards and 3DS2 unless your data shows a different bottleneck#

For first purchases, card plus 3DS2 is usually the primary path. EMV 3DS is designed for card-not-present authentication, and card-based digital wallet initiation requires SCA under PSD2 Article 97(1)(b) unless an RTS exemption applies. If this flow is underperforming, first confirm whether the issue is scope, exemption logic, challenge handling, or issuer response before you add a new method.

Apply scenario rules before changing rails#

For renewals, treat exemption use narrowly. SCA applies when a payer creates, amends, or first initiates a recurring series, and the recurring exemption depends on the same amount and same payee. If those conditions change, route for review instead of assuming exempt repeat charging.

For high-friction segments, use a strict trigger: if decline clusters persist after compliant SCA setup and clean 3DS2 execution, test direct bank transfers before expanding to a broader APM mix.

Use a concrete checkpoint list before you move beyond cards#

Before you broaden payment methods, make sure the current card path is actually understood.

If those checks still point to issuer-path friction, a direct bank-transfer pilot is the next controlled test.

Treat crypto as a separate strategic choice#

Crypto should be a program-specific decision, not a default workaround for card-auth friction.

Keep it on a separate track with legal, finance, operations, and support review, and recheck any EBA Q&A you rely on against current legal text before hard-coding controls.

Use exemptions carefully and document every approval#

Use exemptions to reduce friction only when you can prove why each exempted payment qualified.

Treat each exemption as a controlled exception to the SCA default, not as a standing conversion setting.

Under PSD2 Article 97, SCA applies when the payer accesses an account online, initiates an electronic payment, or performs a remote action that may imply fraud risk. SCA means at least two elements from the knowledge, possession, and inherence categories. Exemptions can reduce friction, but they do not remove the need for strict eligibility logic, evidence retention, and rollback rules.

Use recurring and low-risk exemptions for the cases they were built for#

Most teams rely on two exemption families: recurring transactions and transaction risk analysis, or TRA.

For recurring transactions, the condition is narrow. The SCA control point is when the payer creates, amends, or first initiates a same-amount, same-payee series under RTS Article 14. Later payments in that same series may be exempted, subject to general authentication requirements. If amount, payee, or series terms change, stop treating it as a clean recurring exemption case.

TRA is different. It is optional, applies to remote electronic payments, and depends on the PSP identifying the transaction as low risk within reference fraud-rate constraints. EBA Q&A gives card-payment examples such as 0.13% or less at €100 or below, and 0.06% up to €250, with the same principle continuing for higher bands up to €500. If your processor says TRA is active, keep evidence of the policy basis, the monitored fraud-rate view, and which payments were actually exempted.

Handle subscriptions differently from one-time payments#

A subscription model is not automatically exempt. The key question is whether each renewal is still part of the same-amount, same-payee series that was properly authenticated at setup or amendment.

For subscriptions, keep a clear trail from the renewal to the initial authenticated event: customer mandate or checkout acceptance record, amount, payee identity, date of first authenticated payment, and recurring-series reference from your PSP. If your team cannot trace that link, your exemption position is weak.

For one-time payments, keep full SCA as the default and use exemptions only when conditions are provable. Low-value remote exemptions under Article 16 require all controls, not just one: an individual transaction limit of €30, plus either a cumulative amount since last SCA not exceeding €100 or no more than five consecutive remote electronic transactions.

Keep an approval record that survives an audit or dispute#

Approval should tie to both policy and execution. Assign clear ownership for each exemption path and keep transaction-level records that show why each payment met the policy.

Set one non-negotiable rule: if exemption logic for a payment cannot be evidenced, route that payment through full two-factor authentication.

Also treat Article 18 fraud-rate breaches as an immediate escalation point. Even where formal reporting sits with the PSP, if monitored fraud rates exceed the applicable reference rate, pause exemption use on the affected flow, confirm what is being applied, and move the flow back to full SCA until the evidence is clean.

Fix declines with a triage path that avoids rework#

Treat declines as a triage problem first, not a routing problem.

Separate compliance-path failures, issuer behavior, and processor or routing defects before you change anything. The wrong first move creates repeat failures and noisier data.

Classify the decline before you touch routing#

Start with this split:

Run two checks early:

1. Do not treat HTTP 200 from a processor API as payment success. Diagnose with decline detail fields such as refusalReason and refusalReasonCode.
2. If required 3DS is skipped and the processor declines, treat it as a compliance-path defect, not an issuer problem.

Use a strict first-response sequence#

Use this order:

1. Verify SCA and 3DS2 configuration on the failed flow.
2. Inspect 3DS telemetry.
3. Test smart routing only after steps 1 and 2 are clean.

For step 1, confirm the failed payment was routed through the intended PSD2 and SCA logic. Check exemption flags, whether 3DS was requested, and whether authorization happened after authentication. If that evidence is incomplete, fix configuration before anything else.

For step 2, inspect transStatus and transStatusReason. Together, they are often the fastest way to confirm whether authentication qualified and why a transaction was denied. If you see issuer-driven soft declines, move to an authenticated retry path when applicable.

For step 3, treat routing as optimization, not as a compliance control. Routing can reduce failures and help with downtime, but it does not satisfy PSD2 on its own.

Choose customer messaging only when backend fixes will not solve it#

Use customer messaging when the transaction already followed the correct authentication path and the issuer still declined. In that case, ask the customer to contact their issuer or use a different payment method, and keep messaging generic. Do not expose raw refusal details.

Use backend fixes when the failure is on your side: skipped 3DS, broken exemption logic, challenge handoff defects, or processor or acquirer errors on one path. Avoid repeated retries through the same failing path; some setups can temporarily block cards after repeated failed authentication attempts.

Escalate immediately on cohort spikes#

Do not wait for a normal optimization cycle when you see:

• sudden spikes in failed authentication in a specific EU transaction cohort, for example one country, issuer group, or processor path
• concentrated increases in Issuer Unavailable or Acquirer Error
• repeated failed-authentication patterns that appear suspicious and should feed transaction monitoring
• PSP incidents that may fall under the DORA incident-reporting regime from 17 January 2025

When these patterns appear, pause retry experiments on the affected flow, open a joint investigation with the processor, and preserve the trail from authentication event to authorization response.

Build a weekly monitoring pack for compliance and finance leaders#

Use a weekly pack to make PSD2 and SCA control performance reviewable with transaction-level proof, not summary-only reporting.

For each control view, include a direct link to the underlying record that shows what happened and why the outcome was accepted.

The pack should answer two questions quickly: is SCA working on in-scope EU transactions, and are unresolved issues creating financial or legal risk faster than they are being closed?

What the weekly pack should contain#

Tie each metric to a proof point#

Treat this as an audit-readiness control: if the pack says SCA worked, a reviewer should be able to open the 3DS2 record and verify that the authentication path ran. Processor dashboard screenshots are not enough unless they reconcile to transaction-level records.

For exemptions, the key control is the approval basis. If you use the Transaction Risk Analysis exemption under Article 18, keep the approval record and fraud-rate support for the amount band used. For card TRA, the EBA summary cites €100 with 0.13% or less, €250 with 0.06% or less, and the same principle extending up to €500. If evidence is incomplete, treat the exemption metric as unreliable and move the affected flow back to full SCA until recordkeeping is fixed.

A practical check is to sample report transactions each week and confirm the metric can be recreated from raw records. A common failure is counting "3DS requested" as "SCA completed," which can hide challenge drop-off.

Add the finance and risk view, not just the compliance view#

Do not stop at compliance reporting. Include three standing checkpoints: unresolved decline clusters, aging investigations, and decision backlog. These show where revenue loss is repeating, where control failures remain open, and whether governance delays are slowing closure.

Also show transaction-monitoring signals alongside authentication metrics. RTS expects monitoring mechanisms to detect unauthorized or fraudulent transactions, and ECB and EBA reporting states that SCA-verified transactions were generally less susceptible to fraud than non-SCA transactions, especially cards. Your pack should therefore show whether fraud patterns are shifting in the same cohorts where failed authentication or exemption usage is rising.

Use a one-page executive summary#

Keep page one tight so legal, risk, and finance can align in one review:

• Scope covered this week: EU payment cohorts, processors, and payment types included
• SCA headline: success rate, failure rate, and biggest movement vs prior week
• Exemption headline: where exemptions were used, evidence completeness, and any rollback recommendation
• Incident headline: major active incidents, customer or revenue impact, and processor dependencies
• Governance headline: oldest open escalation, decisions needed this week, and owner for each
• Explicit ask: what needs legal interpretation, processor remediation, and finance planning if issues remain open

If the summary cannot show where the control is working, where it is weak, and what decision is blocked, it is not strong enough for PSD2 and SCA risk governance.

Handle country and program variation without losing control#

Treat variation as expected.

One operating decision will not automatically hold across the whole European Union. PSD2 is an EU directive, but it was transposed into national law by 13 January 2018, so the legal base is shared while implementation and supervisory interpretation can differ by market.

Use a two-layer governance model. Keep one baseline PSD2 policy across in-scope payment flows, anchored to Directive (EU) 2015/2366 and the RTS on SCA and secure communication in Delegated Regulation (EU) 2018/389. Add local addenda only where country counsel, a competent-authority view, or a specific program setup changes how the baseline is applied.

Keep each addendum narrow and traceable:

• Market and affected payment method or program
• Exact interpretation question
• Legal reviewer
• Processor capability relied on
• Effective date and rollback trigger
• Relevant RTS reference and any dated EBA Single Rulebook Q&A entry used

Date-check interpretive references before rollout. The EBA states that it does not systematically refresh published Q&As after legislative amendments.

Use a three-step confirmation path before changing live handling for affected EU transactions:

1. Legal review confirms the interpretation and states whether it is market-specific or reusable.
2. Your processor confirms execution details in writing, for example how 3DS2 or exemption logic behaves for that cohort. Treat processor documentation as implementation guidance, not legal advice.
3. Roll out in a controlled way with a limited cohort, and monitor transaction-level evidence in the weekly pack.

Maintain a dated change log for every interpretation decision, link each entry to the relevant Regulatory Technical Standards reference, and retire entries that are no longer current.

Roll out in 30-60-90 days with verification gates#

Use a 30-60-90 plan as an internal control cadence, not a PSD2 deadline.

Move to the next phase only when you can prove better control and auditability.

First 30 days#

Start by establishing the real baseline: where SCA is triggered, where failures happen, and who owns each fix. For mixed one-time and recurring flows, separate first setup or amendment of a recurring series from later charges, because that first recurring setup needs explicit SCA handling.

Keep exemption design narrow and condition-based while you baseline. If you cannot point to the eligibility rule, approver, and retained evidence for an exemption, freeze it and route that cohort through full authentication.

Include fraud monitoring in this phase. RTS expects transaction monitoring mechanisms to detect unauthorised or fraudulent payments, so legal mapping alone is not enough.

By 60 days#

Prioritize the card path first: fix 3DS2 configuration and routing before you broaden alternatives. Your key control check is dynamic linking, because remote-payment authentication must be tied to the specific amount and payee, and changes invalidate the authentication code.

Use 3DS2 telemetry to confirm that frictionless and challenge paths are behaving as intended and that device data is consistently available for risk assessment. Use processor guidance as implementation input, then verify against your own logs.

If card friction remains concentrated in a defined segment, pilot APMs narrowly. For example, SCT Inst-based transfers can make funds available within ten seconds, but treat this as a measured pilot, not a blanket compliance workaround.

By 90 days#

By this phase, the model must be auditable, not just operational. Controls and exemptions should be documented, periodically tested, and reviewable by operationally independent experts in IT security and payments.

Set a hard gate for TRA exemptions: monitor fraud against the applicable reference thresholds, and escalate immediately if rates exceed them. If exemption use is ceased for excess fraud, do not resume until rates are back at or below the reference level.

If you want a practical extension for recurring billing after this phase, see Strong Customer Authentication (SCA) for Subscription Platforms: Reducing Decline Rates.

The practical takeaway for compliance, risk, and finance teams#

The practical outcome is fewer PSD2 and SCA surprises because you can prove how each EU transaction was handled, not just describe policy intent. Make ownership explicit, keep decision evidence tied to the transaction, and separate legal-interpretation questions from execution failures early.

PSD2 has applied since January 2018, and the SCA requirement came into force on 14 September 2019. The binding technical layer is Commission Delegated Regulation (EU) 2018/389, which sets requirements payment service providers must meet. If you cannot show where SCA applied, where an exemption was attempted, and who owned the exception path, you are depending on assumptions rather than evidence.

What "provably covered" should mean in practice#

For SCA, the first checkpoint is simple: can you evidence that authentication used two or more elements across knowledge, possession, and inherence where required? For remote journeys, confirm that the transaction record, processor response, and 3DS2 data align before you tune conversion.

For exemptions, treat them as conditional. The RTS allows limited exemptions based on risk, amount, and recurrence, not blanket carve-outs. For TRA, EBA Q&A clarifies that the PSP applying the exemption must be below the reference fraud rate, and the payer's PSP still makes the final call to accept an exemption, require SCA, or decline.

Where teams usually get caught out#

The common failures are ownership and evidence gaps: SCA scope decisions are unclear, exemption assumptions continue after conditions change, or teams optimize declines without a usable proof trail.

At minimum, keep:

• the control owner and escalation path for each SCA or exemption decision
• transaction and 3DS2 logs showing what happened in authentication
• exemption approval records with date, approver, eligibility basis, and rollback trigger
• incident notes where rule interpretation is still unresolved

The next move worth making#

Start with your highest-volume EU transactions and run your control matrix plus a weekly monitoring pack as an operating choice. Then answer three questions with records, not opinions: where SCA applies in your real journey, where exemption use is evidence-backed, and which issues need legal or compliance review before product or processor optimization.