Home/Research library/Compliance Slows Launches

Guide · Authentication and payment regulation

Transaction Risk Analysis Exemptions

Transaction Risk Analysis Exemptions: How TRA Works Under SCA “Low risk” has two very different meanings in payments. A merchant's fraud system may classify a transaction as low risk because the customer is returning, the device looks familiar, the purchase fits previous behavior

Source-imported researchEditorial verification pending

Research draft awaiting independent review. This material was adapted from an existing research library. Provider-specific promotions have been excluded automatically; facts, regulatory requirements, and conclusions must be verified before the page is indexed publicly.

Transaction Risk Analysis Exemptions: How TRA Works Under SCA

“Low risk” has two very different meanings in payments.

A merchant's fraud system may classify a transaction as low risk because the customer is returning, the device looks familiar, the purchase fits previous behavior, and no fraud rules were triggered.

That alone does not make the payment eligible for the regulatory Transaction Risk Analysis exemption under Strong Customer Authentication.

The Transaction Risk Analysis exemption, or TRA exemption, allows a payment service provider to omit Strong Customer Authentication for a qualifying remote electronic payment that its real-time risk analysis identifies as low risk, provided the transaction amount and the PSP's regulated fraud performance satisfy the applicable thresholds.

Three tests therefore matter simultaneously:

individual transaction risk

transaction value

the relevant PSP's fraud rate.

And even when the acquiring side applies or requests the exemption, the payer's payment service provider—typically the card issuer—retains the ultimate decision over whether to accept the exemption or require authentication.

That makes TRA operationally important for merchants, but not entirely merchant-controlled.

The editorial brief correctly makes this the central issue: TRA is not simply a merchant declaring that a transaction is safe; eligibility depends on risk analysis, regulated fraud-rate requirements, transaction thresholds, the PSP/acquirer, and issuer acceptance.

What is the Transaction Risk Analysis exemption?

Transaction Risk Analysis is one of the exemptions from Strong Customer Authentication (SCA) provided by the EU's SCA Regulatory Technical Standards under PSD2.

Article 18 of Commission Delegated Regulation (EU) 2018/389 allows a PSP not to apply SCA to a payer-initiated remote electronic payment where the PSP identifies the transaction as presenting a low level of risk and the regulation's other conditions are met.

For TRA to apply, the payment must satisfy three broad conditions:

The PSP's applicable fraud rate must be at or below the regulatory reference fraud rate.

The transaction must not exceed the applicable exemption threshold value.

Real-time analysis must not identify specified risk indicators inconsistent with treating the payment as low risk.

This is why TRA differs from an ordinary merchant fraud decision.

A merchant risk engine might output:

risk_score = low

The regulatory question is more like:

transaction low risk

AND

PSP fraud performance meets regulatory threshold

AND

transaction value is within eligible band

AND

issuer accepts/no SCA step-up required.

[Internal link opportunity: SCA Exemptions]

How does Transaction Risk Analysis work?

The logic operates at two levels.

Level 1: the individual transaction

The relevant PSP performs real-time risk analysis.

The EU rules specifically require the PSP to consider whether indicators such as the following are present:

an abnormal spending or behavioral pattern;

unusual information about the payer's device or software access;

signs of malware during the authentication process;

a known fraud scenario;

an abnormal payer location;

a high-risk payee location.

The regulation also requires the risk assessment to take account of factors including previous spending patterns, transaction history, location where relevant, and abnormal payment behavior. These factors are combined into an individual transaction risk score.

So TRA is not:

“Transaction below €500 = exempt.”

The transaction must first pass a real-time risk assessment.

Level 2: the PSP's portfolio fraud performance

The PSP must also satisfy the applicable regulated fraud-rate threshold.

Under the EU rules, fraud rates are calculated by the PSP for the relevant transaction type on a rolling quarterly basis. The calculation covers the value of fraudulent or unauthorized remote transactions relative to the total value of remote transactions of that type, including payments processed with SCA and under the relevant exemptions.

This creates an important relationship:

The higher the value of transaction a PSP wants to exempt through TRA, the lower the PSP's permitted reference fraud rate becomes.

That mechanism prevents TRA from becoming an unlimited “low-risk” declaration.

Who can apply or request a TRA exemption?

This is where regulatory terminology and payment implementation can sound contradictory unless the roles are separated.

The regulated exemption belongs to PSPs

Article 18 gives payment service providers the ability not to apply SCA when its conditions are satisfied.

EBA guidance confirms that both:

the payer's PSP, generally the issuer; and

the payee's PSP, generally the acquirer,

can apply relevant SCA exemptions within their respective roles. The payer's PSP retains the ultimate decision.

Merchants can influence the request

In card ecommerce implementations, a merchant or its payment infrastructure may identify a transaction as a candidate for TRA and signal a preference for no challenge.

EMVCo's current 3-D Secure documentation supports a TRA exemption indicator through the 3DS flow. It describes the merchant/acquirer performing risk assessment and the 3DS request communicating that no challenge is requested because Transaction Risk Analysis has already been performed. The issuer-side Access Control Server then evaluates the transaction and may apply the exemption.

So the useful distinction is:

Merchant / merchant risk system

→ can provide data, risk signals and an exemption preference

PSP / acquirer

→ operates within the regulatory TRA framework and applies/submits the exemption where supported

Issuer

→ makes the payer-side decision and can still require SCA.

A merchant should therefore not say:

“We qualify for TRA.”

without clarifying whose regulatory fraud rate and exemption capability it means.

How do fraud rates affect TRA eligibility?

The EU TRA framework deliberately links transaction value to PSP fraud performance.

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

Exemption threshold value

Maximum reference fraud rate

€100

0.13%

€250

0.06%

€500

0.01%

For remote electronic credit transfers, the corresponding reference fraud rates are:

Exemption threshold value

Maximum reference fraud rate

€100

0.015%

€250

0.01%

€500

0.005%

These values are set out in the annex to the SCA Regulatory Technical Standards.

For card ecommerce, this means a PSP operating at a 0.08% applicable fraud rate might meet the regulatory card threshold for the €100 TRA band but not the €250 band.

A PSP with sufficiently low fraud to satisfy the 0.01% reference rate could potentially use the €500 band for otherwise qualifying remote card transactions.

The thresholds are ceilings, not automatic approvals.

A €75 transaction does not qualify merely because it is under €100.

It still has to be identified as low risk by the required real-time risk analysis.

Merchant fraud rate and PSP TRA fraud rate are not the same thing

This distinction deserves special emphasis.

Suppose Merchant A reports:

0.02% fraud

on its own ecommerce portfolio.

That does not independently prove regulatory eligibility for a €250 or €500 TRA exemption.

Article 18 refers to the fraud rate reported and calculated by the payment service provider under Article 19.

A merchant's fraud performance can still matter commercially and operationally.

An acquirer may consider merchant-specific:

fraud history;

transaction behavior;

product risk;

customer characteristics;

device information;

authorization history;

when determining how exemption strategies should be applied.

But regulatory TRA eligibility should not be reduced to:

merchant fraud rate < 0.06% → €250 TRA.

The regulated PSP's qualifying performance is a separate requirement.

The PSP must continue monitoring fraud performance

TRA eligibility is not static.

Article 20 requires PSPs using TRA to report when relevant monitored fraud rates exceed the reference level. If a monitored rate remains above the applicable reference fraud rate for two consecutive quarters, the PSP must stop using TRA for the affected transaction type and threshold range.

The PSP can resume use once the regulatory restoration conditions are satisfied and the relevant notification process is followed.

The regulation also imposes monitoring and auditing requirements around the methodology, models and reported fraud rates used for TRA.

For merchants, the implication is practical:

TRA availability can change because of PSP-level fraud performance even when the merchant's own fraud rate has not materially changed.

That is one reason exemption strategies should be configurable rather than hard-coded permanently into checkout logic.

How does transaction value affect TRA?

Transaction value determines which fraud-rate threshold must be met.

Consider three hypothetical card payments under the EU framework.

€70 transaction

Potentially fits within the €100 band.

The PSP would need to satisfy the card reference fraud rate applicable to that band, and the individual transaction would still need to be classified as low risk.

€180 transaction

It exceeds the €100 threshold.

For TRA to be available, the relevant PSP would need to satisfy the stricter threshold associated with the €250 band.

€400 transaction

It falls within the €500 band.

The applicable card reference fraud rate becomes 0.01%, together with the other regulatory TRA conditions.

The logic is therefore:

higher transaction value

→ stricter portfolio fraud-performance requirement.

This is fundamentally different from the low-value exemption.

EU and UK TRA thresholds are now different

Merchants operating across the EEA and UK should not treat TRA thresholds as one permanently harmonized European configuration.

The current UK SCA framework uses different sterling exemption threshold values:

UK TRA threshold

Remote card reference fraud rate

£85

0.13%

£220

0.06%

£440

0.01%

The corresponding UK credit-transfer fraud thresholds are 0.015%, 0.01% and 0.005%.

The FCA's current supervisory reporting framework also explicitly tracks PSP TRA performance across the £85, £220 and £440 bands.

For engineering teams, this means a rule such as:

if amount < 250 then request_TRA

is too simplistic.

Eligibility depends on:

regulatory jurisdiction;

currency/threshold;

PSP eligibility;

transaction risk;

actual provider implementation;

issuer outcome.

Who decides whether the TRA exemption is accepted?

The issuer-side decision is one of the most important parts of the TRA model.

EBA guidance describes the payer's PSP as holding the ultimate decision about whether to accept or apply an exemption. Where the acquiring side has applied an exemption, the issuer can:

accept it;

apply an exemption itself;

revert to SCA where technically feasible;

or reject the exempted transaction.

So:

TRA candidate

does not mean:

SCA impossible.

And:

TRA requested

does not mean:

TRA accepted.

EMV 3DS supports that operating model. The protocol can communicate that Transaction Risk Analysis has already been performed and that a challenge is not requested, but the issuer-side ACS evaluates the transaction and determines whether a challenge remains necessary.

Can an issuer override a TRA exemption request?

Yes.

More precisely, the payer's PSP retains the ultimate decision and may require SCA rather than accepting the acquiring-side exemption request.

This is why merchants should avoid product copy or internal specifications saying:

“TRA transactions do not require authentication.”

The more accurate statement is:

Qualifying transactions may be submitted under TRA without requesting a customer challenge, but the issuer can still require SCA.

This distinction has direct checkout implications.

Your payment flow needs to support:

TRA requested

↓

issuer accepts

→ continue without challenge

or:

issuer requires SCA

→ move customer into authentication.

What is a soft decline?

In card-payment operations, soft decline is commonly used for a decline indicating that additional customer authentication is required and that the payment may be retried through an authenticated flow.

It is an implementation/payment-network concept rather than the legal definition of the TRA exemption itself.

Visa, for example, documents response code 1A as “additional customer authentication required.”

Conceptually:

merchant/acquirer attempts TRA

↓

issuer does not accept unauthenticated processing

↓

authentication-required response

↓

merchant/PSP retries through an SCA-capable 3DS flow

↓

customer authenticates

↓

authorization continues.

The exact response handling varies by provider and payment-network implementation, so merchants should verify their PSP's retry and step-up behavior rather than writing network assumptions directly into checkout code.

TRA is not the same as a frictionless 3DS flow

Another frequent source of confusion is the word frictionless.

EMV 3-D Secure can produce a frictionless authentication outcome because enough information is available for the issuer to authenticate without presenting an interactive challenge.

TRA is different.

With TRA, a qualifying regulatory exemption is being used so that SCA does not have to be applied to the transaction.

The customer experience may look similar:

no visible challenge.

The regulatory and technical reasons are different.

That distinction matters when merchants analyze:

exemption acceptance;

3DS performance;

liability;

issuer behavior;

authentication completion;

authorization performance.

[Internal link opportunity: 3D Secure Compliance]

TRA versus the low-value exemption

Both can reduce the need for SCA.

Their eligibility logic is different.

Transaction Risk Analysis exemption

Low-value exemption

Main basis

Real-time low-risk determination + PSP fraud rate + value threshold

Low transaction value + cumulative/count conditions

EU remote card transaction amount

Up to applicable €100/€250/€500 TRA band

Individual payment generally ≤ €30

PSP fraud-rate requirement

Yes

Not the TRA reference-rate test

Individual real-time TRA required

Yes

Not the Article 18 TRA test

Issuer can still require SCA

Yes

Best understood as

Risk-performance exemption

Small-payment exemption

The low-value exemption has its own cumulative-amount and transaction-count logic, which should be handled in the dedicated article rather than collapsed into TRA.

[Internal link opportunity: Low-Value Transaction Exemptions]

The useful distinction is:

Low value:

“This transaction is small enough, and the cumulative/count conditions permit the exemption.”

TRA:

“This transaction is within a permitted value band, the relevant PSP's fraud performance qualifies for that band, and real-time analysis says this specific transaction is low risk.”

What TRA means for merchants

TRA can be strategically useful because authentication challenges create another point at which a payment can fail or a customer can abandon checkout.

But minimizing challenges is not the same objective as maximizing successful legitimate payments.

Consider two strategies.

Strategy A

Request TRA aggressively.

Possible result:

more exemption attempts;

more issuer step-ups or declines;

fewer initial authentication requests.

Strategy B

Authenticate more transactions upfront.

Possible result:

more customer authentication;

fewer exemption-related step-ups;

potentially different authorization behavior.

Which produces the better commercial outcome depends on the merchant's:

issuer mix;

markets;

amounts;

customers;

fraud profile;

PSP/acquirer;

3DS implementation;

payment performance.

The objective should therefore be:

optimize total payment success and fraud performance, not exemption rate in isolation.

Better payment data can improve TRA execution

Merchant data does not replace the PSP's regulated TRA requirements.

It can still make risk assessment more informative.

EMV 3DS is designed to convey data that supports issuer risk assessment, and EMVCo describes the protocol as enabling merchants and issuers to share information used for transaction risk analysis and authentication decisions.

Depending on the payment implementation, useful data can include signals related to:

account/customer history;

transaction characteristics;

device context;

shipping and billing information;

purchase behavior;

merchant relationship;

authentication context.

Merchants should prioritize accurate and consistent signals rather than maximizing the number of fields populated.

Poor data can create a different problem:

transaction appears unfamiliar because the merchant's integration failed to provide information that would have made it understandable.

What merchants should ask their PSP about TRA

Before relying on Transaction Risk Analysis as part of an authentication strategy, ask:

Regulatory eligibility

Which entity is applying the TRA exemption?

Which jurisdictions are supported?

Which transaction-value bands does the provider currently qualify for?

Risk assessment

Does the PSP determine TRA eligibility automatically?

Can merchant risk signals influence the decision?

Which information should the merchant provide?

3D Secure

Is TRA communicated through EMV 3DS?

When is an authorization-only exemption route used, if applicable?

Can the issuer step up to SCA without losing the checkout session?

Issuer response

How is an issuer-required authentication response exposed?

Does the PSP automatically retry through 3DS?

Does merchant integration need to initiate the retry?

Reporting

Can the merchant distinguish:

TRA eligible;

TRA requested;

TRA accepted;

SCA step-up;

authentication completed;

authorization approved;

authorization declined?

Those are not equivalent states.

How should merchants measure TRA performance?

A useful TRA dashboard should not stop at:

TRA exemption rate.

Measure the complete path.

Exemption attempt rate

How many eligible transactions were submitted using TRA?

Issuer acceptance

How often did the payer-side PSP allow the transaction to continue without SCA?

Step-up rate

How often did a TRA attempt lead to authentication being required?

Authentication completion

When SCA was required, did the customer successfully complete it?

Authorization rate

What percentage of transactions were ultimately approved?

Checkout completion

Did the exemption strategy actually improve completed customer payments?

Fraud

Did fraud performance change?

Technical failure

Were payments lost because step-up or retry handling failed?

Then segment those metrics by:

issuer;

country;

card type;

PSP/acquirer;

transaction-value band;

customer cohort;

device/platform.

A global TRA conversion rate can hide the same problem as a global authorization rate: one issuer segment can perform badly while the aggregate appears healthy.

Example TRA payment flow

Consider an illustrative €180 ecommerce card payment in an EEA market.

Step 1 — Merchant receives payment request

Customer attempts to buy a €180 product.

Step 2 — Merchant risk controls run

The merchant sees:

established customer;

normal purchase behavior;

recognized account;

no major internal fraud signals.

The merchant considers the payment a possible TRA candidate.

That does not itself create regulatory eligibility.

Step 3 — PSP/acquirer evaluates TRA

Because €180 exceeds the €100 EU TRA band, the relevant PSP would need to qualify for the applicable €250 threshold.

For remote card payments, that corresponds to a reference fraud rate of 0.06% or below, together with the other Article 18 requirements.

Step 4 — Real-time analysis

The PSP's required risk analysis checks the transaction and applicable risk factors.

No disqualifying risk indicator is identified.

Step 5 — Exemption is communicated

The transaction is submitted with the relevant TRA exemption signaling through the supported payment/3DS architecture.

Step 6A — Issuer accepts

No SCA challenge is required.

Authorization proceeds.

or:

Step 6B — Issuer requires authentication

The issuer decides not to accept unauthenticated processing.

The payment flow moves to SCA.

Step 7 — Measure final outcome

The merchant should record:

TRA attempted → issuer response → SCA outcome if any → authorization outcome.

Without that chain, the merchant cannot tell whether poor performance comes from:

TRA strategy;

issuer behavior;

authentication;

authorization;

or technical retry handling.

TRA launch checklist

Before launching a TRA strategy, verify:

Which SCA jurisdiction applies?

Is the transaction actually in SCA scope?

Which regulated PSP is applying TRA?

Which TRA bands does that PSP currently support?

Are EU and UK thresholds configured separately where relevant?

How is transaction risk assessed?

Which merchant signals can be supplied?

How is TRA communicated through 3DS or authorization?

Can the issuer require SCA?

What response indicates that authentication is required?

Does the checkout support step-up/retry cleanly?

Can reporting distinguish exemption request from issuer acceptance?

Can results be segmented by issuer, market and transaction value?

Are fraud and authorization performance measured together?

Who monitors provider and regulatory changes affecting TRA?

The broader cluster's goal is to prevent authentication regulation becoming a launch blocker simply because these operating questions were discovered after checkout was already built.

Key takeaway

The Transaction Risk Analysis exemption is a regulated risk-performance framework, not a merchant fraud setting.

For TRA to work:

the individual transaction must be low risk

its value must fit an eligible threshold

the relevant PSP must meet the applicable fraud-rate requirement

the issuer must allow the transaction to proceed without SCA.

Merchants can contribute high-quality data, identify good exemption candidates, choose providers with strong TRA capabilities, build effective 3DS fallback, and optimize the resulting payment flow.

They cannot independently turn their own low merchant fraud rate into regulatory TRA eligibility.

The most scalable implementation therefore looks like:

transaction

→ merchant risk signals

→ PSP real-time analysis

→ TRA eligibility

→ exemption request/application

→ issuer decision

→ either no challenge or SCA step-up

→ authorization

→ performance measurement.

That is also the right way to think about TRA commercially.

The objective is not to avoid SCA at any cost.

It is to apply authentication intelligently enough that legitimate customers encounter no more friction than the regulation, risk, and issuer decision require.

Exact SCA and TRA requirements vary by jurisdiction and payment architecture. Merchants should verify current regulatory requirements, provider eligibility, card-network implementation, and authentication behavior with their payment providers and appropriately qualified advisers before deploying or materially changing a TRA strategy.

🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂

END ARTICLE

SEO / EDITORIAL GUIDANCE — NOT PART OF THE ARTICLE

Recommended SEO package

Transaction Risk Analysis Exemption: How TRA Works Under PSD2 SCA

Meta title:

TRA Exemption Explained | Transaction Risk Analysis & SCA

Meta description:

Learn how the Transaction Risk Analysis exemption works under SCA, including TRA fraud-rate thresholds, transaction limits, PSP eligibility, issuer decisions, 3D Secure and merchant optimization.

Recommended slug:

/authentication-payment-regulation/transaction-risk-analysis-exemption/

Transaction Risk Analysis exemption

Secondary targets:

TRA exemption

SCA TRA exemption

PSD2 Transaction Risk Analysis

SCA risk exemption

transaction risk analysis payments

TRA fraud rate

TRA SCA thresholds

TRA exemption PSD2

transaction risk analysis 3D Secure

TRA issuer exemption

High-intent long-tail queries

how does the TRA exemption work

who qualifies for TRA exemption

who can request a TRA exemption

PSD2 TRA fraud rate thresholds

€100 €250 €500 TRA exemption

can an issuer reject a TRA exemption

TRA exemption vs low value exemption

TRA exemption 3D Secure

merchant fraud rate TRA exemption

how to improve TRA exemption acceptance

SCA soft decline after TRA

UK TRA exemption thresholds

The brief explicitly identifies the relationship among transaction risk, fraud performance, transaction value, the regulated provider, and issuer approval as the article's differentiating subject.

Why it helps

Make merchant fraud rate ≠ regulatory PSP fraud rate a prominent callout

This is the brief's most important misconception to correct.

Keep the threshold table above the fold

€100/€250/€500 is likely a major search destination.

Add the UK threshold comparison as a small secondary table

Prevents EU rules being mistaken for permanent UK rules.

Define soft decline carefully as implementation terminology

Avoids presenting card-network behavior as a PSD2 statutory concept.

Show issuer step-up as a normal outcome

Reinforces that exemption requests are not guaranteed.

Build the practical section around payment measurement

Makes the article useful to Payments/Product teams rather than only Compliance.

Avoid expanding into every SCA exemption

Protects the separate pillar and low-value article from cannibalization.

The brief itself requires TRA to remain distinct from the low-value exemption and specifically asks who can apply it, how fraud rates work, who accepts it, and what merchants can improve.

READER-FACING VISUAL ASSETS — NOT PART OF THE ARTICLE

Visual 1 — The TRA Eligibility Equation

This should be the hero visual.

REAL-TIME TRANSACTION ANALYSIS

Low risk?

TRANSACTION VALUE

Within eligible threshold?

PSP FRAUD RATE

Below applicable reference rate?

ISSUER DECISION

Exemption accepted?

↓

TRA can proceed without SCA

Central annotation:

Merchant risk alone is not enough.

Suggested alt text:

Transaction Risk Analysis exemption eligibility showing individual transaction risk, transaction value, PSP fraud rate and issuer acceptance.

Visual 2 — EU TRA Threshold Ladder

REMOTE CARD PAYMENT

≤ €100

PSP fraud rate ≤ 0.13%

↓

Potential TRA

≤ €250

PSP fraud rate ≤ 0.06%

↓

Potential TRA

≤ €500

PSP fraud rate ≤ 0.01%

↓

Potential TRA

Beside it, smaller credit-transfer figures:

€100 → 0.015%

€250 → 0.01%

€500 → 0.005%

Footer:

Threshold eligibility does not replace real-time risk analysis or issuer decision.

Visual 3 — Merchant Fraud Rate vs PSP Regulatory Fraud Rate

Two separate gauges:

Merchant risk view

Merchant A

Fraud performance: illustrative merchant metric

Used for:

internal fraud strategy;

PSP risk decisions;

optimization.

Regulatory TRA view

Acquirer / relevant PSP

Regulated reference fraud rate

Used for:

determining available TRA threshold band.

Arrow:

Merchant performance may influence provider strategy

but:

Merchant rate ≠ Article 19 PSP fraud rate

This would directly attack the misconception the brief wants removed.

Visual 4 — TRA Payment Flow

CUSTOMER PAYMENT

↓

MERCHANT RISK SIGNALS

↓

PSP / ACQUIRER

Real-time risk analysis

↓

TRA conditions satisfied?

↙ ↘

NO YES

↓ ↓

SCA TRA signaled/requested

↓

ISSUER

↙ ↘

ACCEPTS REQUIRES SCA

↓ ↓

Authorization 3DS step-up

↓

Authorization

Suggested annotation:

The issuer retains the payer-side decision.

Visual 5 — TRA vs Low-Value Exemption

TRA

Low value

Based on transaction amount

Yes

PSP reference fraud rate

Yes

No TRA test

Real-time risk analysis

Required for TRA

Not Article 18 TRA

EU card threshold

€100 / €250 / €500 bands

≤€30 individual payment plus accumulation/count rules

Issuer can require SCA

Yes

Merchant controls outcome

This should link visually to Low-Value Transaction Exemptions.

Visual 6 — Soft Decline Recovery Flow

TRA ATTEMPT

↓

Issuer requires authentication

↓

AUTHENTICATION-REQUIRED RESPONSE

↓

Retry through SCA-capable 3DS

↓

Customer authentication

↓

Authorization

Side-by-side with failure mode:

TRA ATTEMPT

↓

Authentication required

↓

No step-up/retry path

↓

PAYMENT LOST

This visual turns a regulatory issue into an engineering requirement.

Practical downloadable/checklist asset

A useful gated or ungated asset would be a TRA Implementation Worksheet containing:

Regulatory configuration

market;

SCA jurisdiction;

currency;

applicable TRA thresholds.

Provider configuration

PSP/acquirer;

qualifying bands;

supported exemption channel;

3DS exemption support;

retry/step-up behavior.

Merchant data

customer history available;

device data;

billing/shipping data;

transaction history;

risk score.

Reporting

exemption requested;

issuer acceptance;

soft decline/auth-required result;

SCA result;

authorization result;

fraud outcome.

This would be considerably more useful to a payment team than a generic “PSD2 compliance checklist.”

Internal-link strategy

Use the four links prioritized in the brief:

how SCA exemptions work more broadly → SCA Exemptions

how the low-value exemption differs from TRA → Low-Value Transaction Exemptions

how 3D Secure carries authentication and exemption data → 3D Secure Compliance

when merchants need Strong Customer Authentication → SCA Requirements for Merchants

These are the internal-link opportunities explicitly identified for this article.

I would avoid long sections on recurring payments, MITs, or other exemptions here because this page should own the narrow query:

How does TRA determine whether a low-risk transaction can proceed without SCA?

FAQ opportunities

If a visible FAQ is useful for the site, the strongest questions are:

What is the Transaction Risk Analysis exemption?

A regulatory SCA exemption for qualifying remote payments identified by a PSP as low risk, subject to transaction-value and PSP fraud-rate requirements.

What are the TRA fraud-rate thresholds?

For current EU remote card payments, the reference rates are 0.13% at €100, 0.06% at €250, and 0.01% at €500.

Does a merchant's fraud rate determine TRA eligibility?

No. The regulatory fraud-rate requirement concerns the relevant payment service provider's calculated fraud rate, although merchant-level fraud performance may influence provider risk decisions.

Can an issuer reject a TRA exemption?

The payer's PSP retains the ultimate decision and can require SCA or reject the exempted transaction.

What is the difference between TRA and the low-value exemption?

TRA combines real-time risk analysis with PSP fraud-rate and transaction-value requirements. The low-value exemption uses separate small-payment amount and cumulative/count conditions.

Is TRA the same as frictionless 3D Secure?

No. A frictionless 3DS authentication outcome and a regulatory TRA exemption can both avoid an interactive challenge, but they are different technical and regulatory outcomes.

Schema recommendation

Use:

Article

BreadcrumbList

FAQPage only if the FAQ copy is visibly included on the published page

The page does not need exotic schema to perform well. Its competitive advantage should be the precision of the payment mechanics and the clarity of the TRA decision model.

Strongest editorial framework

Give the article one memorable operating sequence:

Risk → Threshold → PSP → Issuer → Step-up → Authorization → Measurement

That turns TRA from an obscure PSD2 exemption into a process a payment team can actually design, instrument, and optimize.

Need help narrowing down payment options?

Answer a few questions about your business and compare the capabilities that matter to you.

Explore matching options ↗