On this page
- Regulatory basis
- The three-tier fraud rate threshold table
- Who applies TRA: the acquirer-issuer hierarchy
- Real-time analysis requirements
- Soft decline: when the issuer overrides a TRA request
- Liability shift mechanics
- PSP implementation
- Conversion context
- TRA vs Delegated Authentication
- Geographic scope
- PSD3/PSR implications (as-of 2026-07-21)
- Key terms
Transaction Risk Analysis (TRA)
Transaction Risk Analysis (TRA)
TRA is an Strong Customer Authentication (SCA - PSD2)|SCA exemption mechanism defined in Article 18 of Commission Delegated Regulation (EU) 2018/389 (the RTS on SCA under PSD2). It allows an acquiring PSP to skip 3D Secure 2 (3DS2)|3DS authentication for a remote card payment when the transaction is identified as low-risk and the PSP's portfolio fraud rate stays below applicable EBA thresholds. TRA is the primary conversion-optimisation tool for European ecommerce checkout — it was created specifically to counteract the conversion friction introduced by SCA mandates.
Regulatory basis
TRA is codified in Article 18 of Commission Delegated Regulation (EU) 2018/389, which sets out the Regulatory Technical Standards on SCA and Secure Communication under PSD2. The exemption applies to remote, card-not-present electronic payments in the EEA. The TRA exemption is only available for EMV 3DS — specifically Visa Secure v2.2 and Mastercard Identity Check v2.1 extension or v2.2. American Express and Diners Club do not support TRA at authentication in the EEA and UK; all Amex EEA transactions require SCA regardless of exemption type. (Checkout.com SCA Docs, 2026-07-15; Checkout.com Blog, 2023-06-12)
The three-tier fraud rate threshold table
The EBA RTS Annex sets three fraud-rate/transaction-value bands (as-of 2026-07-21, under PSD2 RTS EU 2018/389 — pending PSR Level 2 RTS):
| PSP portfolio fraud rate (CNP remote card transactions) | Maximum exemptible transaction value |
|---|---|
| ≤ 0.13% | Up to €100 |
| ≤ 0.06% | Up to €250 |
| ≤ 0.01% | Up to €500 |
No individual transaction above €500 can be exempted via TRA regardless of fraud rate. (Stripe Documentation, retrieved 2026-07-21; EBA Single Rulebook Q&A 2018_4034; Checkout.com Blog, 2023-06-12)
The fraud rate is calculated as: total value of unauthorised/fraudulent remote card transactions ÷ total value of all remote card transactions executed or acquired by the PSP. The denominator includes both SCA-authenticated and exempted transactions. The rate must be refreshed quarterly (every 90 days). (EBA Single Rulebook Q&A 2018_4032; SEON, updated 2026-05-22)
In 2024, the aggregate observed TRA fraud rate for remote e-money transactions in the EEA was 0.142% (as-of 2025-12-15) — above the 0.13% threshold required to exempt transactions up to €100, indicating that some PSPs operating under TRA were at or near the ceiling of the first-tier band. The EBA/ECB flagged this in their 2025 Joint Payment Fraud Report (EBA/REP/2025/40). (EBA/ECB Joint Payment Fraud Report, 2025-12-15)
The Checkout.com (2023) figure citing Visa Europe's estimate that 40–50% of ecommerce transactions by volume could be eligible for TRA exemption is a 2023 Visa estimate and may be outdated. No 2025–2026 primary source confirms or updates this figure.
Who applies TRA: the acquirer-issuer hierarchy
Acquirer/PSP (most common): The acquiring PSP requests a TRA exemption during authentication or authorisation. Only the fraud rate of the requesting PSP needs to be below the reference threshold — it is assessed independently per PSP. (EBA Single Rulebook Q&A 2018_4034)
Issuer (independent): The issuing bank can independently apply the TRA exemption without a request from the acquirer, using the same fraud rate thresholds applied to its own portfolio. When the issuer applies TRA without a request, liability for any resulting fraud shifts to the issuer. (Checkout.com Blog, 2023-06-12; Adyen Docs, retrieved 2026)
Fraud rate is PSP-level, not merchant-level: TRA can be contractually outsourced to individual merchants or gateways, but the fraud rate making a PSP eligible must still be calculated on the basis of the acquirer PSP's aggregate executed/acquired transactions — not the individual merchant's transactions. Merchants with high individual fraud rates can therefore negatively affect their acquirer's eligibility. (Mangopay/Nethone, 2023-02-13; EBA Single Rulebook Q&A)
TRA use in 2024: Approximately 29% of remote card payments without SCA in the EEA in 2024 were exempted under TRA (as-of 2025-12-15). The EBA described TRA usage as "rarely used, although increasing over time." (EBA/ECB Joint Payment Fraud Report EBA/REP/2025/40, 2025-12-15)
Real-time analysis requirements
Article 18 of the EBA RTS requires acquiring PSPs to perform real-time risk analysis before applying the TRA exemption. Checkout.com (2023) and Mangopay (2023) identify four categories of minimum required checks:
- Behavioural analysis — detecting sudden or anomalous changes in user spending/activity patterns compared to prior behaviour
- Device and browser fingerprinting — verifying whether the device used is known and consistent with prior sessions
- Pattern matching — checking the transaction against known fraud scenarios and blacklists
- Location verification — flagging abnormal locations, high-risk geographies, or sanctioned countries in the payment chain
SEON (2026-05-22) adds that PSPs must confirm the transaction does not show evidence of malware installation. PSD3/PSR will raise this to mandatory transaction monitoring for ALL PSPs (not just those applying TRA), broadening the baseline compliance obligation. (Morrison Foerster, 2026-04-30)
Soft decline: when the issuer overrides a TRA request
When an acquirer requests a TRA exemption and the issuer declines it, the response returns a soft decline — a specific error code indicating that SCA is required, rather than a hard decline of the transaction. PSD2 requires PSPs receiving a soft decline to be able to retry the transaction with a full SCA challenge flow; platforms unable to handle soft declines will see these transactions fail at payment. (GPayments, 2026-03-24)
Checkout.com specifics: Soft decline for a rejected TRA exemption at authorisation returns response code 20154. The merchant must retry with 3ds.enabled: true and challenge_indicator: challenge_requested_mandate. (Checkout.com SCA Docs, 2026-07-15)
Detecting whether the exemption was honoured: There is no definitive confirmation from issuers that a TRA exemption was accepted. Ravelin (2025-07-24) identifies two proxy signals: (1) the transaction was authorised without a soft decline (authorisation route), or (2) frictionless authentication was performed (authentication route). GPayments (2026-03-24) flags monitoring issuer override rates as a best practice — high override rates signal that the PSP's fraud model or transaction quality is triggering issuer concern.
Liability shift mechanics
When the acquirer requests TRA and the issuer accepts: liability for any resulting fraud remains with the acquirer/merchant — not the issuer. Applying the TRA exemption means the acquirer gives up the Liability Shift that full SCA/3DS would have transferred to the issuer. (Solidgate, date unknown; Adyen Docs, retrieved 2026)
When the issuer applies TRA independently (without an acquirer request): liability shifts to the issuer. (Checkout.com Blog, 2023-06-12)
Liability scope: Solidgate states that applying TRA means "the provider gives up the liability shift that SCA would have transferred to the issuer" in all cases [https://solidgate.com/glossary/transaction-risk-analysis-exemption/]. Ravelin (2025-07-24) states that "each card scheme will have different rules on whether liability shifts to the acquirer/merchant or issuer when an exemption is accepted," implying scheme-level variation rather than a universal rule [https://www.ravelin.com/blog/sca-transaction-optimization-guide-exemptions]. Solidgate's framing appears to be a simplification of the most common case (acquirer-requested TRA accepted by issuer); Ravelin's is more granular. Neither is definitively contradicted by EBA primary text found in this run.
PSP implementation
Stripe uses machine learning (Stripe Radar) to perform real-time TRA. As of 2026-07-21, Stripe offers TRA exemptions up to 250 EUR for EEA merchants and 220 GBP for UK/Swiss merchants — operating at the 0.06% fraud-rate band. Stripe's "Data Only" flow (3DS v2.2+) is a separate non-TRA mechanism that sends authentication data to card networks without triggering liability shift. (Stripe Documentation, retrieved 2026-07-21)
Adyen handles TRA exemption requests automatically via its Authentication Engine by default (Option 1). Merchants can alternatively configure Dynamic 3DS rules or specify exemption preference per transaction via API fields (Option 3), overriding the default logic. Adyen does not publicly disclose which threshold band it operates under. (Adyen Docs, retrieved 2026)
Checkout.com supports TRA via the API field 3ds.exemption: "transaction_risk_assessment". TRA is supported at both authentication and authorisation stages for Visa and Mastercard; American Express and Diners Club are excluded. (Checkout.com SCA Docs, 2026-07-15)
PSP TRA ceiling: Stripe publicly caps its TRA at 250 EUR (EEA), consistent with the 0.06% band. Adyen's documentation does not specify a maximum TRA transaction value they apply, implying they may operate at the 500 EUR ceiling for qualifying merchants. This is an undisclosed commercial difference between PSPs, not a regulatory contradiction.
Conversion context
SEON (2026-05-22) reports that some industries experienced payment drop-offs of up to 40% following SCA implementation — TRA is the primary mechanism designed to restore this lost conversion by routing low-risk transactions around 3DS friction.
Mangopay (2023-02-13) claimed TRA "may become the most widely used SCA exemption" because "most transactions will qualify" — this assessment predates two years of real-world SCA data. The EBA 2025 fraud report showing a 0.142% aggregate TRA fraud rate (above the 0.13% first-tier ceiling) suggests the practical eligibility picture is more constrained than Mangopay's 2023 view.
TRA vs Delegated Authentication
TRA and Delegated Authentication are distinct mechanisms addressing different scenarios:
- TRA: Skips authentication entirely for low-risk transactions. No 3DS flow occurs. The transaction is exempted based on the PSP's real-time risk assessment and portfolio fraud rate.
- Delegated Authentication: The merchant or PSP authenticates the cardholder on behalf of the issuer within the 3DS flow. The cardholder is not redirected to the issuer's interface. A 3DS authentication event still occurs — it is just performed by a delegated party rather than the issuer directly.
TRA is the higher-conversion option (no authentication step at all) but carries acquirer liability and is subject to EBA fraud thresholds. Delegated Authentication often achieves high frictionless rates (Adyen 88–91%, Stripe Link 89–93% per the Delegated Authentication concept page) but requires PSP certification and is not a complete SCA bypass. (Ravelin, 2021/2024; GPayments, 2026-03-24)
Geographic scope
EEA: Full PSD2 SCA enforcement applies when both the issuer and acquirer are based in the European Union. For transactions where one party is inside the EEA and one outside, PSD2 requires "best efforts" but full enforcement applies only to intra-EEA transactions. (Mangopay, 2023-02-13)
UK: Post-Brexit, the UK operates under its own SCA regime (FCA PS19/26) and will not adopt PSD3/PSR. UK and EU are on diverging SCA regulatory paths. UK TRA transaction-value thresholds mirror the EEA bands but are denominated in GBP — Stripe's UK cap (220 GBP) is approximately equivalent to the 250 EUR / 0.06% band. PSPs processing EU and UK transactions must monitor issuer override behaviour separately for each jurisdiction. (UK FCA PS19/26; Stripe Documentation; GPayments, 2026-03-24)
American Express: All Amex EEA and UK transactions require SCA — the TRA exemption is not available for Amex regardless of PSP fraud rate. (Checkout.com SCA Docs, 2026-07-15; Ravelin, 2025-07-24)
PSD3/PSR implications (as-of 2026-07-21)
| Milestone | Date |
|---|---|
| Provisional political agreement (PSD3 + PSR) | 27 November 2025 |
| COREPER endorsement | 23 April 2026 |
| EU Official Journal publication (anticipated) | Mid-2026 |
| PSR applicable | ~21 months after OJ publication (~late 2027/early 2028) |
(Sources: Morrison Foerster, 2026-04-30; Norton Rose Fulbright, 2026-04-03; GR4VY, 2026-06-23)
TRA retained under PSR: All existing SCA exemptions — including TRA, low-value transactions, MIT, trusted beneficiary, and secure corporate payments — are retained under PSD3/PSR. (Norton Rose Fulbright, 2026-04-03; GR4VY, 2026-06-23)
PSR as Regulation (not Directive): Unlike PSD2 (a directive requiring national transposition, producing Member State variation), the PSR is a directly applicable EU Regulation — eliminating cross-border inconsistency in TRA exemption application across all 27 EU members. GR4VY (2026-06-23) states: "The SCA exemption strategy that has worked under PSD2 will continue to work under PSR, with the additional clarity making cross-border consistency easier to achieve."
Potential threshold revision: GPayments (2026-03-24) reports that PSD3 proposes "more granular fraud rate thresholds and potential changes to which party can apply which exemption." The EBA has 22 PSR mandates and 18 PSD3 mandates to deliver; SCA-related RTS are expected in 2026. Until the new Level 2 measures are published, the current PSD2 RTS (EU 2018/389) thresholds remain operative. (EBA Work Programme 2026, published 2025-10)
Broadened transaction monitoring: PSD3 proposes mandatory risk-based transaction monitoring for ALL PSPs — not just those applying TRA exemptions — raising the baseline compliance obligation. (Morrison Foerster, 2026-04-30; SEON, updated 2026-05-22)
Key terms
| Term | Meaning |
|---|---|
| TRA | Transaction Risk Analysis — the risk-based SCA exemption under PSD2 Art. 18 |
| CNP | Card Not Present — the transaction type TRA applies to (remote ecommerce payments) |
| Soft decline | Issuer response rejecting an exemption request; PSP must retry with full SCA |
| Frictionless flow | 3DS authentication completed without a challenge step (not the same as a TRA exemption) |
| Portfolio fraud rate | Total fraudulent value ÷ total transaction value across all a PSP's remote card transactions |
| Liability shift | Transfer of fraud liability from merchant/acquirer to issuer that occurs with 3DS authentication; TRA forgoes this shift |
| PSR | Payment Services Regulation — the PSD3-era directly applicable EU Regulation replacing the PSD2 directive structure |