SCA Exemptions

SCA Exemptions Explained: When Strong Customer Authentication May Not Be Required

Strong Customer Authentication does not mean every eligible European online payment must interrupt the customer with an authentication challenge.

The regulatory framework includes specific SCA exemptions that allow payment service providers to process qualifying mer Authentication (SCA). The aim is to preserve payment security while avoiding authentication friction where the regulation permits a different approach.

But an exemption is not a merchant-controlled bypass.

An SCA exemption means a transaction falls within the SCA framework but meets conditions under which a payment service provider may choose not to apply SCA. The exemption is conditional, and the payer's payment service provider—typically the issuer for a card payment—can still require authentication.

That distinction is particularly important for merchants designing checkout flows. A payment can qualify for a low-value or Transaction Risk Analysis exemption and still be challenged. Conversely, some payment flows do not require SCA because they fall outside its scope rather than because an exemption was used.

This article focuses primarily on the EU/EEA PSD2 framework while identifying material UK differences where useful. The editorial brief specifically targets SCA exemptions, including low-value payments, Transaction Risk Analysis, trusted beneficiaries and secure corporate payments.

As of August 20, 2026, the current EU rules discussed here remain based on PSD2 and its SCA Regulatory Technical Standards. The successor PSD3/Payment Services Regulation package has reached political agreement but has not yet been formally adopted; EU institutions currently expect final adoption/publication later in 2026. Businesses implementing longer-term authentication strategies should therefore monitor the transition rather than assuming today's rules are permanent.

What are SCA exemptions?

PSD2 requires payment service providers to apply Strong Customer Authentication in specified circumstances, including when a payer initiates an electronic payment transaction. For remote electronic payments, the authentication framework also includes dynamic linking to the amount and payee.

Commission Delegated Regulation (EU) 2018/389 then establishes circumstances in which payment service providers are allowed not to apply SCA.

Relevant exemptions include:

•low-value remote transactions;

•Transaction Risk Analysis (TRA);

•trusted beneficiaries;

•recurring transactions;

•secure corporate payment processes;

•certain transfers between accounts belonging to the same person;

•contactless point-of-sale transactions;

•unattended transport and parking terminals;

•limited account-information access.

Not all of these are equally relevant to ecommerce merchants.

The crucial principle is:

SCA required by default

→ does an exemption apply?

→ if yes, the PSP may use it

→ payer's PSP can still require SCA.

An exemption therefore creates regulatory permission not to authenticate. It does not create a right for the merchant to force the issuer to accept an unauthenticated transaction.

How does an SCA exemption request work?

For card ecommerce, several participants can be involved:

Customer

→ Merchant

→ gateway / PSP

→ acquirer

→ card network

→ issuer

The merchant may configure its payment integration or PSP to attempt particular exemption strategies.

The merchant itself does not legally “approve” the exemption.

In the EU framework, the exemption is exercised by payment service providers. Where an acquirer seeks to apply a Transaction Risk Analysis exemption, EBA guidance confirms that the payer's PSP—the issuer—makes the ultimate decision. If the issuer does not accept the requested TRA exemption, it can require SCA or, where authentication cannot technically be performed, decline the transaction.

Modern EMV 3-D Secure can transmit exemption-related information. EMVCo documents indicators for requests involving TRA, trusted-list, low-value and secure-corporate exemptions. The issuer-side Access Control Server can evaluate the request and decide whether a cardholder challenge is needed.

That produces an important technical distinction:

3D Secure is an authentication protocol. An SCA exemption is a regulatory concept.

3DS can help communicate and execute an exemption strategy, but using 3DS does not make a transaction exempt, and requesting an exemption does not guarantee a frictionless result.

[Internal link opportunity: Strong Customer Authentication Explained]

[Internal link opportunity: 3D Secure Compliance]

How does the low-value transaction exemption work?

The low-value exemption is intended to allow some small remote electronic payments to proceed without SCA.

Under the current EU SCA Regulatory Technical Standards, a remote electronic payment can qualify where:

•the individual transaction does not exceed €30; and

•either the cumulative amount of previous qualifying remote transactions since the payer's last SCA does not exceed €100;

•or the number of previous qualifying remote transactions since the last SCA does not exceed five consecutive transactions.

The key word is and.

A €20 purchase is not automatically exempt merely because it is below €30.

Consider an illustrative sequence:

SCA performed

→ €18 payment

→ €22 payment

→ €27 payment

→ €25 payment.

The issuer must still consider the applicable cumulative/count conditions. Eventually SCA must be reapplied once the conditions no longer allow use of the exemption.

From a merchant's perspective, that means:

Transaction amount alone cannot tell you whether the low-value exemption will be accepted.

The payer's PSP has information the merchant may not possess about the customer's previous qualifying transactions.

The UK low-value exemption uses different amounts

Businesses operating both EU/EEA and UK payment flows should not hard-code one set of “European SCA thresholds.”

Current UK FCA technical standards use:

•£25 maximum individual remote payment;

•£85 cumulative amount since the last SCA;

•or no more than five previous consecutive qualifying transactions.

So:

Jurisdiction

Individual amount

Cumulative condition

Count condition

EU SCA RTS

€30

€100 since last SCA

Up to five previous transactions

UK SCA RTS

£25

£85 since last SCA

Up to five previous transactions

This is a good example of why authentication requirements should be configured by regulatory market rather than represented in merchant code as one global Boolean such as:

sca_required = transaction_amount > 30

[Internal link opportunity: Low-Value Transaction Exemptions]

How does the Transaction Risk Analysis exemption work?

Transaction Risk Analysis, or TRA, allows a payment service provider to avoid SCA for a remote electronic payment it identifies as low risk, provided detailed regulatory conditions are satisfied.

TRA is more sophisticated than:

“Our fraud engine thinks this payment looks safe.”

The EU rules require, among other things:

•real-time transaction risk analysis;

•specified risk factors to be considered;

•transaction value to remain within the relevant exemption threshold;

•the PSP's applicable fraud rate to remain at or below regulatory reference fraud rates.

For remote electronic card-based payments under the current EU rules, the reference thresholds are:

Maximum transaction value

Maximum reference fraud rate

€100

0.13%

€250

0.06%

€500

0.01%

Transactions above €500 do not receive an additional higher TRA exemption tier under the current table.

The regulation also requires real-time analysis to consider warning signs including abnormal spending or behavioral patterns, unusual device information, known fraud scenarios, abnormal payer location and high-risk payee location.

The fraud threshold belongs to the PSP

This point causes significant merchant confusion.

The statutory TRA benchmark is based on the payment service provider's relevant fraud rate, not simply the merchant's internal chargeback or fraud percentage.

A merchant with exceptionally low fraud cannot independently declare:

“We qualify for €500 TRA.”

Its acquirer or other relevant PSP needs to satisfy the regulatory conditions for the exemption it is applying.

Merchant-level performance can still matter operationally because PSPs may use their own risk policies and merchant data when deciding how aggressively to request exemptions.

But the regulatory TRA framework and a merchant's own fraud score are not the same metric.

UK TRA thresholds are different in sterling

The current UK framework retains analogous TRA rules but uses exemption threshold values of:

•£85

•£220

•£440

with corresponding remote-card reference fraud rates of 0.13%, 0.06%, and 0.01%.

Again, the EU and UK should not be implemented as though their monetary thresholds are identical.

TRA eligibility can change

TRA is not a permanent provider entitlement.

Under the EU rules, PSPs must monitor their relevant fraud rates. If a rate exceeds the applicable threshold, regulatory reporting and ultimately cessation rules can apply.

The UK framework similarly requires relevant PSPs to cease using the exemption in an affected threshold range where the applicable monitored fraud rate exceeds the reference rate for two consecutive quarters.

So a merchant should not build checkout architecture around the assumption:

“Our provider supports TRA today, therefore every eligible transaction will remain exempt indefinitely.”

[Internal link opportunity: Transaction Risk Analysis Exemptions]

What is the trusted-beneficiary exemption?

The trusted-beneficiary exemption applies where the payer has previously added the payee to a trusted-beneficiary list maintained through the payer's account-servicing payment service provider.

Under the EU rules:

•SCA is required when the payer creates or amends that trusted-beneficiary list;

•subsequent transactions to a beneficiary already on the list may be processed without SCA, subject to the regulatory conditions.

This is not the same as a merchant deciding:

“This customer trusts us because they have purchased here five times.”

The relevant trusted relationship is established through the payer's PSP under the regulatory framework.

EMV 3DS also contains support for communicating trusted-list exemption information where relevant.

For many card merchants, this exemption may be less strategically important than TRA or low-value exemptions, but it remains an important part of the overall SCA framework.

What is the secure corporate payment exemption?

The secure corporate payment exemption addresses certain payment processes used by businesses rather than consumers.

Under the EU SCA RTS, SCA may be omitted for electronic payments initiated by legal persons using dedicated payment processes or protocols that:

•are available only to payers who are not consumers; and

•provide security that the competent authority considers at least equivalent to the level required by PSD2.

This should not be simplified to:

“Corporate cards are exempt from SCA.”

A B2B payment does not automatically qualify merely because:

•the card says “business”;

•the buyer works for a company;

•the invoice is commercial.

The regulatory conditions concern the dedicated payment process or protocol and its security.

The current UK framework contains an analogous secure corporate payment exemption where the dedicated processes are only available to non-consumer payers and the FCA is satisfied with their equivalent security.

For merchants selling to both consumers and businesses, the useful implementation question is therefore:

Can our PSP reliably identify the payment processes that genuinely qualify, rather than treating all B2B payments as exempt?

What about recurring payments?

Recurring transactions create one of the most important SCA distinctions for subscription businesses.

Under Article 14 of the EU SCA RTS, SCA is required when a payer:

•creates;

•amends;

•or initiates for the first time

a series of recurring payments with the same amount and same payee.

Subsequent transactions in that series may then be processed without SCA under the recurring-transaction exemption.

Conceptually:

Customer sets up €15 monthly subscription

→ SCA at setup/first transaction

→ €15 same merchant next month

→ potentially exempt

→ €15 following month

→ potentially exempt.

If the defined series is amended, SCA may need to be applied again.

Recurring exemption is not the same as a merchant-initiated transaction

This is critical for subscription businesses.

The regulatory recurring exemption deals with a series of transactions with the same amount and the same payee.

A merchant-initiated transaction, or MIT, is a different concept. Certain subsequent payments initiated by the merchant under an appropriate prior mandate can fall outside the SCA requirement rather than being processed under Article 14's recurring exemption.

EBA guidance also clarifies that establishing a remote mandate for later merchant-initiated transactions can itself require SCA where the action creates payment-fraud or abuse risk.

Therefore:

fixed recurring payment exemption

≠

MIT treatment.

The separate cluster articles on recurring payments and merchant-initiated transactions should own those distinctions in depth.

What other SCA exemptions exist?

The regulatory framework contains additional exemptions that may be important outside a typical ecommerce checkout.

Contactless point-of-sale transactions

EU rules permit qualifying low-value contactless payments to proceed without SCA subject to applicable amount, cumulative, and transaction-count conditions.

Unattended transport and parking terminals

Payments at unattended terminals for transport fares or parking can receive a specific exemption.

Transfers between accounts belonging to the same person

A credit transfer can qualify where the payer and payee are the same natural or legal person and both relevant accounts are held by the same account-servicing PSP.

Limited payment-account information access

Separate provisions allow SCA exemptions for certain forms of payment-account information access subject to detailed conditions.

For most ecommerce merchants, these are secondary to:

•low value;

•TRA;

•recurring payments;

•and, in appropriate cases, corporate or trusted-beneficiary arrangements.

Exempt transactions and out-of-scope transactions are not the same thing

This is one of the most important SCA implementation distinctions.

Exempt transaction

The transaction falls within the SCA framework, but an exemption allows a PSP not to apply SCA.

Examples include:

•low-value payment;

•TRA;

•trusted beneficiary;

•qualifying recurring transaction.

Out-of-scope transaction

The SCA requirement does not apply to the transaction in the same way in the first place.

Depending on the exact facts, examples can include:

•qualifying merchant-initiated transactions;

•mail-order or telephone-order transactions;

•certain “one-leg” transactions involving a PSP outside the relevant regulatory territory.

EBA fraud-reporting guidance explicitly distinguishes merchant-initiated transactions and one-leg card transactions from payments processed under the Article 11–18 SCA exemptions.

The EBA also recognizes that genuine mail-order and telephone-order payments are outside the electronic-payment logic underlying SCA, although whether a particular technical flow actually qualifies as MOTO depends on how the transaction is initiated.

This distinction matters operationally because these labels describe different legal reasoning:

In SCA scope + exemption

versus:

not subject to SCA for that transaction classification.

A payment integration should preserve that distinction rather than encode every transaction without customer authentication as:

sca_exempt = true

A better data model might distinguish:

•sca_required

•sca_exemption_requested

•sca_exemption_type

•sca_out_of_scope_reason

•authentication_requested_by_issuer

•authentication_result.

That becomes particularly valuable when merchants later analyze authorization performance.

Why can an issuer still request authentication?

Because exemption eligibility does not remove the payer's PSP from the decision.

EBA guidance is explicit that the payer's PSP ultimately determines whether to accept or apply an exemption. An issuer may require SCA even when the acquiring side has requested TRA.

EMV 3DS reflects this operationally. The merchant or 3DS server can communicate that a challenge is not requested and identify an applicable exemption, while the issuer-side ACS can still decide that further authentication is required.

So the actual flow can be:

Merchant / PSP identifies possible exemption

↓

Acquiring side sends exemption information

↓

Issuer evaluates transaction

↓

either:

Exemption accepted → no cardholder challenge

or:

Issuer requires SCA → 3DS challenge

or, in some circumstances:

transaction cannot proceed as submitted.

A robust checkout needs to support all three outcomes.

Exemption does not always mean “frictionless”

This wording is worth treating carefully.

Merchants understandably want SCA exemptions because fewer authentication steps can reduce customer interruption.

But:

SCA exemption ≠ guaranteed frictionless checkout.

The issuer may still challenge.

Technical routing can fail.

The provider may not support a particular exemption for that transaction.

The merchant's desired exemption may not be eligible.

A card scheme or PSP may impose additional implementation conditions.

A more defensible goal is:

Use the correct exemption where the transaction and provider architecture support it, while retaining a reliable path to authentication when the issuer requires SCA.

How should merchants build an SCA exemption strategy?

The objective should not be to maximize the percentage of transactions labeled “exempt.”

The objective should be to improve the complete payment outcome while remaining within the applicable rules.

A practical framework is:

•Determine whether the transaction is in SCA scope

Before thinking about exemptions, classify the payment.

Ask:

•Which regulatory market applies?

•Is the payment customer-initiated?

•Are the relevant PSPs inside the SCA jurisdiction?

•Is this a genuine MIT?

•Is the transaction electronic?

•Is it a recurring-series setup or subsequent charge?

Only then move to exemption analysis.

•Identify the applicable exemption

Potential categories might include:

low value

TRA

recurring

trusted beneficiary

secure corporate.

Do not apply one generic no_sca label.

•Ask what the PSP and acquirer actually support

Merchants should verify:

•which exemptions can be requested;

•which are applied automatically;

•whether 3DS is still invoked;

•how exemption indicators are transmitted;

•what fallback occurs if the issuer requires SCA;

•whether country or card-type restrictions exist;

•what reporting identifies the exemption attempted and the final authentication outcome.

Regulation establishes the permissions.

Implementation determines whether the merchant can use them effectively.

•Build authentication fallback

An exemption strategy without a step-up path is fragile.

The checkout should be capable of moving from:

exemption requested

to:

issuer requests authentication

to:

customer completes SCA

without unnecessarily losing the transaction.

•Measure the whole outcome

Track by exemption type:

•exemption attempts;

•issuer acceptance;

•authentication step-ups;

•authorization rate;

•authentication completion;

•technical failures;

•fraud;

•chargebacks where relevant;

•checkout completion.

An exemption that removes authentication but produces more issuer declines may not improve the merchant's payment outcome.

•Segment the analysis

Results may differ by:

•country;

•issuer;

•card type;

•amount;

•PSP/acquirer;

•customer cohort;

•exemption type.

Do not judge an SCA strategy from one global conversion number.

•Maintain jurisdiction-specific configuration

The EU and UK threshold examples alone show why this matters.

Your authentication rules should be capable of representing:

market

→ SCA scope

→ available exemption

→ current threshold

→ provider support

→ issuer outcome.

That is much safer than embedding regulatory assumptions directly into checkout code.

SCA exemption launch checklist

Before launching or materially changing an exemption strategy, verify:

•Which jurisdiction's SCA rules apply?

•Is the payment genuinely within SCA scope?

•If not, what is the documented out-of-scope reason?

•If it is in scope, which exemption is being requested?

•Does the transaction meet the regulatory conditions?

•Which PSP—issuer, acquirer, or another relevant provider—is applying the exemption?

•Does the merchant's PSP support the exemption technically?

•Can the issuer still step the customer up to SCA?

•Does the checkout support that fallback?

•Can reporting distinguish exemption requests from issuer decisions?

•Can performance be analyzed by market, issuer and exemption type?

•Are regulatory thresholds maintained outside hard-coded application logic where practical?

•Has the team distinguished recurring exemptions from merchant-initiated transactions?

•Have EU and UK configurations been reviewed separately?

•Who owns monitoring future regulatory changes?

Key takeaway

SCA exemptions are not loopholes around authentication.

They are deliberately defined parts of the authentication framework.

The low-value exemption can reduce authentication on qualifying small payments.

TRA can allow low-risk remote transactions to proceed without SCA where the relevant PSP satisfies strict risk and fraud-rate conditions.

Trusted-beneficiary and secure-corporate exemptions solve different payment scenarios.

Recurring payments have their own rules.

And none of those should be confused with transactions that are outside SCA scope in the first place.

For merchants, the most useful operating principle is:

classify the transaction

→ determine SCA scope

→ identify a valid exemption if applicable

→ request it through the appropriate payment infrastructure

→ allow the issuer to decide

→ support authentication fallback

→ measure the resulting payment performance.

SCA exemptions can reduce unnecessary customer friction.

They cannot guarantee its absence.

The merchant that designs for both outcomes—exemption accepted and authentication required—has a much more scalable payment architecture than one built around the assumption that an exemption request will always be honored.

Exact SCA requirements depend on jurisdiction, payment flow, PSP roles, transaction classification, applicable regulatory rules and provider implementation. Businesses should verify their current requirements with appropriately qualified advisers and payment providers before deploying or materially changing an authentication strategy.

🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂

END ARTICLE

SEO / EDITORIAL GUIDANCE — NOT PART OF THE ARTICLE

Recommended SEO package

SCA Exemptions Explained: Low Value, TRA, Recurring Payments & More

Meta title:

SCA Exemptions Explained | PSD2 Authentication Rules

Meta description:

Learn how SCA exemptions work under PSD2, including low-value payments, Transaction Risk Analysis, recurring transactions, trusted beneficiaries, corporate payments and issuer step-ups.

Suggested slug:

/authentication-payment-regulation/sca-exemptions/

SCA exemptions

Secondary targets:

•Strong Customer Authentication exemptions

•PSD2 SCA exemptions

•SCA exemption rules

•payment authentication exemptions

•low-value SCA exemption

•TRA exemption

•Transaction Risk Analysis exemption

•recurring payment SCA exemption

•trusted beneficiary exemption

•corporate payment SCA exemption

Useful long-tail queries include:

•what are SCA exemptions

•who can request an SCA exemption

•can an issuer reject an SCA exemption

•SCA exempt vs out of scope

•low value SCA exemption limit

•PSD2 low value exemption €30

•how does TRA exemption work

•SCA exemption recurring payments

•merchant initiated transaction vs SCA exemption

•does 3D Secure apply when SCA is exempt

•SCA exemptions UK vs EU

Recommended featured-snippet definition

Place a concise answer near the beginning:

An SCA exemption is a regulatory condition that allows a payment service provider not to apply Strong Customer Authentication to an otherwise in-scope payment. Common exemptions include low-value transactions, Transaction Risk Analysis, trusted beneficiaries, recurring payments and secure corporate payment processes. An exemption does not guarantee that the issuer will allow the transaction without authentication.

This directly targets the article's informational intent and preserves the most important qualification in the brief.

Editorial recommendations

I would retain the article's central differentiation around three questions:

Is SCA in scope?

↓

If yes, is an exemption available?

↓

If requested, will the issuer accept it?

That framework is more useful than organizing the article as a simple catalogue of exemptions.

A few additional editorial improvements would strengthen the page:

Recommendation

Editorial value

Make Exempt ≠ Out of Scope a prominent callout

This is one of the most frequently confused concepts and is explicitly required by the brief.

Keep EU and UK thresholds visibly separate

Prevents outdated/generalized “PSD2 threshold” advice.

Give TRA its own compact data table

The exemption is difficult to understand without connecting value thresholds to PSP fraud rates.

Add an issuer-decision diagram

Shows why an exemption does not guarantee no challenge.

Keep 3DS separate from SCA

Avoids implying that protocol choice itself determines regulatory eligibility.

Treat recurring payments and MITs as neighboring but separate concepts

Prevents cannibalization with the dedicated recurring/MIT articles.

Add a practical launch checklist

Converts regulatory material into something payment/product teams can use.

The brief specifically requires exemptions to be separated from transactions outside SCA scope and warns against implying a frictionless checkout is guaranteed.

RECOMMENDED VISUAL ASSETS — NOT PART OF THE ARTICLE

Visual 1 — SCA Decision Tree

This should be the main reader-facing diagram.

PAYMENT

↓

IS SCA IN SCOPE?

↙ ↘

NO YES

↓ ↓

Document DOES AN EXEMPTION APPLY?

out-of-scope ↙ ↘

reason NO YES

↓ ↓

SCA EXEMPTION REQUEST /

PSP APPLICATION

↓

ISSUER DECISION

↙ ↘

ACCEPTED SCA REQUIRED

↓ ↓

No challenge Authentication

required step-up

Central callout:

Exemption eligibility does not remove issuer discretion.

Suggested alt text:

Strong Customer Authentication decision tree distinguishing out-of-scope payments, SCA exemptions, issuer acceptance and authentication step-up.

Visual 2 — Exemption vs Out of Scope

A two-column infographic:

SCA exemption

Out of SCA scope

SCA framework applies

SCA requirement does not apply in the same way

Regulatory exemption is used

No exemption is being used

Low value

Certain qualifying MITs

TRA

Genuine MOTO

Trusted beneficiary

Certain one-leg payments

Recurring same amount/payee

Depends on transaction classification

Secure corporate

—

Issuer can still require SCA

Separate scope analysis required

Bottom annotation:

“No customer challenge” does not tell you which regulatory category was used.

This visual is likely to be one of the highest-value assets for both reader understanding and AI/search extraction.

Visual 3 — EU Low-Value Exemption Counter

LAST SCA

↓

Transaction 1

↓

Transaction 2

↓

Transaction 3

↓

...

Each payment must be ≤ €30

AND

Issuer checks:

•cumulative qualifying amount since SCA

OR

•consecutive qualifying payment count

Threshold reached

↓

SCA required again

Add a side note:

EU: €30 / €100 / five

UK: £25 / £85 / five

This helps readers understand why a €20 purchase is not automatically exempt.

Visual 4 — TRA Exemption Matrix

EU remote card payments

Transaction ≤ €100

PSP fraud rate ≤ 0.13%

↓

Potential TRA eligibility

Transaction ≤ €250

PSP fraud rate ≤ 0.06%

↓

Potential TRA eligibility

Transaction ≤ €500

PSP fraud rate ≤ 0.01%

↓

Potential TRA eligibility

Then add underneath:

PLUS real-time risk analysis

PLUS no disqualifying risk signals

PLUS issuer acceptance

The last line is important. Otherwise the graphic could incorrectly imply the thresholds alone create entitlement to exemption.

Visual 5 — Who Controls an SCA Exemption?

MERCHANT

Chooses payment strategy

↓

PSP / ACQUIRER

Assesses eligibility and

may signal/request exemption

↓

NETWORK / 3DS

Carries relevant data

↓

ISSUER

Makes payer-side decision

↓

EXEMPTION ACCEPTED

OR

SCA CHALLENGE

This directly answers two high-intent queries:

Who can request an SCA exemption?

and:

Who decides whether it is accepted?

Visual 6 — Authentication Strategy Reporting Model

For payment operations readers:

TRANSACTION

↓

Jurisdiction

↓

SCA scope

↓

Exemption / out-of-scope classification

↓

Exemption requested

↓

Issuer response

↓

3DS challenge?

↓

Authentication result

↓

Authorization result

↓

Fraud / chargeback outcome

This turns the regulatory topic into a data architecture recommendation.

The merchant should be able to distinguish:

we requested an exemption and it failed

from:

we never requested one

from:

issuer requested SCA

from:

authentication succeeded but authorization failed.

Those are different optimization problems.

Internal-link recommendations

Use the four links prioritized by the brief.

Suggested anchor text:

•how the low-value SCA exemption works in detail → Low-Value Transaction Exemptions

•how Transaction Risk Analysis determines exemption eligibility → Transaction Risk Analysis Exemptions

•when Strong Customer Authentication applies → Strong Customer Authentication Explained

•how 3D Secure supports regulated authentication flows → 3D Secure Compliance

Additional contextual bridges, if those articles exist:

•SCA for subscription payments → Recurring Payments and SCA

•why merchant-initiated transactions are different from exemptions → Merchant-Initiated Transactions and SCA

•market-specific authentication rules → Authentication Requirements by Country

Schema recommendation

Use Article and BreadcrumbList as the baseline.

FAQPage can be appropriate only if a visible FAQ section is actually published. High-value questions would be:

•What is an SCA exemption?

•Who can request an SCA exemption?

•Can an issuer reject an SCA exemption request?

•What is the low-value SCA exemption?

•What is the TRA exemption?

•Are recurring payments exempt from SCA?

•What is the difference between SCA exempt and out of scope?

•Does using an exemption guarantee a frictionless checkout?

Strongest editorial framework

I would give this article one memorable reusable framework:

Scope → Exemption → Request → Issuer Decision → Fallback → Measurement

That sequence captures the operational reality better than “use exemptions to improve conversion” and can become the visual identity of the article within the Authentication and Payment Regulation cluster.