EU platform operators should first map every Article 97 trigger in the payment journey, assign a clear owner, and keep transaction-level evidence for each SCA decision. Next, separate failures by checkout, issuer authentication, authorization, and settlement, document exemptions narrowly, and review weekly 3DS2, decline, and incident data so legal interpretation, processor defects, and revenue risk are handled through the right escalation path.
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:
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.
| Payment event | What to map | SCA note |
|---|---|---|
| One-time card payments | Each payment initiation path against Article 97 triggers | Map the initiation path to the Article 97 trigger |
| Recurring transactions | Creation, amendment, and first initiation | Treat each as an explicit SCA checkpoint under the RTS |
| Subscription payment models | Each charge event, not just the plan label | The commercial model and the legal payment event are not the same |
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:
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.
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.
Use a journey map that shows the event, decision point, expected evidence, and owner for remediation.
| Journey stage | What happens | Where SCA / 3DS2 can fire | Common break | Primary owner |
|---|---|---|---|---|
| Checkout submission | Customer enters card details and confirms payment | Merchant sends data for 3DS2 assessment | Missing or incomplete event logging; poor redirect handling | Product |
| Issuer authentication | Issuer assesses risk and may request a challenge | Issuer-driven 3DS2 via issuer ACS | Challenge drop-off; redirect error; issuer capability mismatch | Product + Risk |
| Authorization outcome | Issuer returns approve or decline | SCA may already be complete; authorization is separate | Decline after successful authentication; unclear decline coding | Risk |
| Settlement and reconciliation | Funds move after auth and clearing | No new SCA step | Communication errors; missing lifecycle status; reconciliation gaps | Ops |
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.
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.
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 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.
| Control | Owner | Evidence artifact | Review cadence | Escalation path |
|---|---|---|---|---|
| SCA trigger interpretation under PSD2 Article 97 | Legal or Compliance | Policy version, scope memo, approval history | On rule change and at least quarterly control review | Legal first, then Product and Risk for implementation |
| RTS exemption approval and exception decisions | Compliance with Risk input | Exception register, defined risk factors, approval history tied to Regulatory Technical Standards | Per approval, plus periodic review; TRA methodology audit at minimum on a yearly basis | Legal and Compliance first; processor only after approval logic is confirmed |
| 3DS2 and issuer authentication performance | Product with Processor manager | Incident log, gateway and ACS telemetry, auth path failure analysis | Weekly | Processor and Product first; Legal only if interpretation or disclosure issues appear |
| Major operational or security incident classification and reporting | Compliance or Incident lead | Incident log, severity assessment, authority notification record where applicable | Per incident | Legal and Compliance immediately; competent-authority route without undue delay if threshold is met |
| Security control testing and audit evidence for RTS measures | Internal audit, Compliance, or Security | Test results, evaluation notes, audit trail | Periodic, documented, and audited | Compliance and senior risk owner |
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.
| Issue | Escalate first | Why |
|---|---|---|
| Whether SCA was required | Legal or Compliance | Issue is rule interpretation |
| Whether an exemption was valid | Legal or Compliance | Issue is rule interpretation |
| Whether an RTS exception was documented correctly | Legal or Compliance | Issue is rule interpretation |
| Whether a major incident may trigger authority reporting | Legal or Compliance | Issue is rule interpretation |
| ACS redirect failures | Processor or Product | Issue is in the authentication path |
| Timeout clusters | Processor or Product | Issue is in the authentication path |
| Issuer-path mismatches | Processor or Product | Issue is in the authentication path |
| Post-auth decline patterns that look operational rather than interpretive | Processor or Product | Issue looks operational rather than interpretive |
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.
Your minimum incident pack should include:
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 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.
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.
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.
| Payment path | Likely conversion impact | Compliance burden | Customer support load | Implementation complexity |
|---|---|---|---|---|
| Card + 3DS2 | Strong when issuer authentication is stable; weaker where challenge drop-off is high | High: SCA scope, exemptions, and evidence must be defensible | Higher when customers fail or abandon issuer challenges | Usually moderate if your card stack is mature |
| Direct bank transfers | Useful to test when card declines cluster after compliant setup | Medium to high: legal treatment still depends on initiation model and market context | Different mix: bank flow questions, transfer status, reconciliation issues | Moderate to high based on provider and ops integration |
| Broader APM mix | Can improve reach in some segments; results are program-specific | Medium to high across additional policy and operational variants | Support complexity rises across more payment journeys | High due to per-method integration and controls |
| Crypto payments | Program-dependent; not a default fix for SCA friction | Program-dependent, with separate legal and finance review | Often high due to refund and status-handling differences | High |
Before you broaden payment methods, make sure the current card path is actually understood.
| Checkpoint | What to verify |
|---|---|
| SCA scope and exemption use | Confirm they are documented against RTS conditions |
| Low-value logic | Check misuse, including the €30 individual threshold and the cumulative €100 condition |
| Decline clusters | Segment them by issuer, country, device, and challenge step |
| Telemetry split | Separate issuer challenge failure from post-auth authorization decline |
| Support themes | Distinguish challenge confusion from true payment-method preference |
If those checks still point to issuer-path friction, a direct bank-transfer pilot is the next controlled test.
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 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.
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.
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.
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.
| Exemption path | Eligibility logic | Approver | Evidence retained | Rollback trigger |
|---|---|---|---|---|
| Subsequent recurring transaction | Same amount, same payee, and part of a series first created, amended, or initiated with SCA | Named payments control owner under approved recurring policy; escalate legal or compliance if terms changed | Initial authenticated setup record, recurring-series ID, amount, payee ID, amendment history, PSP recurring flag | Any amount or payee change, missing initial auth record, or unclear series link |
| TRA low-risk remote electronic payment | PSP assessed the remote transaction as low risk and applicable fraud-rate conditions remain within the Annex reference band | PSP exemption owner plus your internal risk or compliance owner for policy use | PSP exemption reason code, fraud monitoring snapshot, transaction risk result, processor confirmation of Article 18 use when relevant | Monitored fraud rate exceeds applicable reference rate, PSP cannot provide evidence, or exemption evidence is incomplete |
| Low-value remote payment | Individual transaction is €30 or less and cumulative amount since last SCA does not exceed €100, or the count does not exceed five consecutive transactions | Named payments ops owner under written Article 16 policy | Amount check, last-SCA timestamp, cumulative counter, consecutive-transaction counter, exemption flag in payment log | Any threshold breach, counter mismatch, or missing last-SCA reference |
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.
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.
Start with this split:
| Decline class | What usually shows up | First action |
|---|---|---|
| Compliance or authentication failure | Required 3DS2 or SCA step was skipped, or the authentication path was not completed | Confirm the payment went through the required authentication path for the in-scope EU transaction |
| Issuer-side behavior | Soft decline, authentication_required, issuer refusal after authentication, or Issuer Unavailable | Trigger or retry authentication when applicable, then separate issuer refusal from merchant-side defects |
| Processor, acquirer, or routing issue | Acquirer Error, processor-specific refusal codes, or localized failures on one processor path | Review processor response fields, then test routing changes only after the auth path is confirmed clean |
Run two checks early:
refusalReason and refusalReasonCode.Use this order:
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.
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.
Do not wait for a normal optimization cycle when you see:
Issuer Unavailable or Acquirer ErrorWhen 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.
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?
| Section | What to show | Required evidence link | Red flag to call out |
|---|---|---|---|
| SCA success and failure trends | Weekly volume of in-scope payments, authenticated vs not authenticated, failed authentication rate, post-auth authorization decline rate | 3DS2 event records, including processor telemetry showing whether 3DS was supported and attempted, for example the three_d_secure property | Rising failed-authentication rate, or a jump in issuer refusals after authentication |
| Exemption usage | Count and share of payments using each exemption path, plus approval or policy basis for each | Approval or policy record for the exemption decision; for Transaction Risk Analysis cases, retain the fraud-rate basis used for the applicable Article 18 band | Exemption usage rises but evidence is missing, stale, or inconsistent with current fraud performance |
| Incident summary | Opened this week, closed this week, active incidents, affected cohorts, processor involvement, customer impact | Incident log, linked investigation notes, and event trail from authentication to authorization response | Repeat incidents on the same flow without root-cause closure |
| Open escalations | Items awaiting legal, compliance, processor, product, or finance decision | Escalation ticket, owner, decision requested, and due date or oldest-open timestamp | Decision backlog growing faster than issue closure |
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.
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.
Keep page one tight so legal, risk, and finance can align in one review:
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.
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:
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:
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.
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.
| Phase | What you do | Go or no-go gate | Evidence to keep |
|---|---|---|---|
| First 30 days | Baseline current SCA performance, map failure points, assign owners, freeze unapproved exemption logic | Go only if you can show where SCA is triggered, where failures occur, and who owns each fix | Failure map, owner list, weekly metrics snapshot, exemption inventory |
| By 60 days | Deploy priority 3DS2 and routing fixes, pilot APMs where card friction stays high | Go only if dynamic-linking checks pass and pilot cohorts are isolated and measurable | 3DS2 event logs, processor confirmation, pilot cohort definition, test results |
| By 90 days | Lock monitoring cadence, escalation SLAs, and evidence retention for auditability | Go only if controls and exemptions are documented, reviewable, and independently testable | Monitoring pack, SLA log, approval records, retention standard, audit review notes |
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.
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 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 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.
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.
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:
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.
Map every Article 97 trigger across the full user journey before changing payment flows. Cover online account access, electronic payment initiation, and risky remote actions. Then assign an owner and evidence trail for each decision so you can show where SCA applies and where it does not.
Fix the authentication path before you tune conversion. Verify dynamic linking to the specific amount and payee, then use 3DS2 logs to separate challenge drop-off, missing device data, issuer behavior, and processor timeouts. Do not broaden exemptions when the failure cause is not evidenced.
Use exemptions only when the RTS conditions are met and you can prove eligibility. The article points to transaction risk analysis and low-value payments below €30, with one cited condition tied to five consecutive individual remote electronic payment transactions. Approval should sit with your designated internal exemption control owner, with records of the logic, approver, date, and rollback trigger.
Treat first setup, amendments, and first initiation as the main SCA checkpoints. Later unchanged charges can be handled differently only when they remain part of the same-amount, same-payee series. For subscriptions, keep first authorization, plan changes, and later collections separate in reporting and evidence.
Send the issue to legal or compliance first when the question is about scope, interpretation, or exemption validity. That includes whether SCA was required, whether an exemption applied, or whether a major incident may trigger reporting. Send it to processor or product first when the rule is clear but the authentication path failed, such as ACS redirects, timeouts, issuer-path mismatches, or missing authentication data.
Usually they shift risk rather than remove it. Test direct bank transfers only after compliant card and 3DS2 controls are understood and issuer-path friction is persistent. Treat crypto as a separate program-specific decision with legal, finance, operations, and support review, not a default workaround for card-auth friction.
Tomás breaks down Portugal-specific workflows for global professionals—what to do first, what to avoid, and how to keep your move compliant without losing momentum.
With a Ph.D. in Economics and over 15 years of experience in cross-border tax advisory, Alistair specializes in demystifying cross-border tax law for independent professionals. He focuses on risk mitigation and long-term financial planning.
Educational content only. Not legal, tax, or financial advice.
**Start with the business decision, not the feature.** For a contractor platform, the real question is whether embedded insurance removes onboarding friction, proof-of-insurance chasing, and claims confusion, or simply adds more support, finance, and exception handling. Insurance is truly embedded only when quote, bind, document delivery, and servicing happen inside workflows your team already owns.
Treat Italy as a lane choice, not a generic freelancer signup market. If you cannot separate **Regime Forfettario** eligibility, VAT treatment, and payout controls, delay launch.
**Freelance contract templates are useful only when you treat them as a control, not a file you download and forget.** A template gives you reusable language. The real protection comes from how you use it: who approves it, what has to be defined before work starts, which clauses can change, and what record you keep when the Hiring Party and Freelance Worker sign.