PSD2's Strong Customer Authentication requirements have been in force across the EU and EEA since March 2022. The enforcement trajectory has varied considerably by member state and by institution type, but at this point the regulatory expectation is settled: electronic payments above certain thresholds require multi-factor authentication, and exemptions from that requirement are conditional on fraud rate performance that must be monitored and reported.
What's less settled — and what continues to create compliance burden for fraud teams in particular — is the interaction between SCA requirements, transaction risk analysis (TRA) exemptions, and the operational reality of running fraud controls at payment scale. This article focuses on what fraud teams are actually responsible for under PSD2 and where the compliance gaps typically appear.
The TRA exemption and what it requires
PSD2 allows issuers and payment service providers to skip Strong Customer Authentication for low-risk transactions under the Transaction Risk Analysis exemption. The exemption is tiered by transaction value: transactions under €30 are generally exempt without condition; transactions between €30 and €500 are conditionally exempt based on the PSP's fraud rate for transactions in that value band.
The fraud rate thresholds for TRA exemption use are:
For remote electronic card payments: 0.13% for transactions up to €100, 0.06% for transactions up to €250, and 0.01% for transactions up to €500. These are reference fraud rates — if your fraud rate in a value band exceeds the threshold, you lose the exemption for that band and must apply SCA to all transactions in it.
This creates a direct operational link between fraud team performance and compliance status. If fraud detection degrades — or if a new attack pattern that your detection doesn't cover gains traction — your TRA exemption eligibility degrades with it. The compliance team is effectively dependent on the fraud team's detection performance for regulatory standing.
Monitoring and reporting obligations
PSPs using TRA exemptions are required to maintain and report fraud rate data by value band on at least a quarterly basis to their National Competent Authority. The reporting requirement isn't difficult by itself. What's difficult is maintaining the data infrastructure to support it accurately.
Accurate fraud rate calculation requires confirmed fraud labels — transactions that have been definitively identified as fraudulent, not just flagged or reviewed. Chargebacks are one source of confirmed fraud labels, but they have significant lag (typically 30-90 days) and only capture a subset of fraud incidents (only those where the cardholder disputed the transaction). For operational TRA monitoring, fraud teams need faster, more complete labeling processes than chargebacks provide.
Institutions that don't have systematic fraud labeling processes — beyond waiting for chargeback files — are running their TRA compliance calculations on incomplete data. They may be understating their fraud rate against the regulatory threshold, which creates regulatory exposure when a review reveals the gap.
The exemption application record
When a PSP applies a TRA exemption to a transaction, that decision is logged and must be defensible. If a transaction that was exempted from SCA under TRA subsequently turns out to be fraud, the exemption decision is subject to regulatory review. Was the transaction assessed in accordance with documented TRA methodology? Was the fraud rate for that value band within the threshold at the time? Was the transaction amount correctly categorized?
In practice, this means fraud teams need to maintain audit logs of exemption decisions — not just whether an exemption was applied, but what the fraud rate was at the time of the decision and how the transaction was characterized for threshold purposes. Most fraud platforms don't automatically generate this audit trail in a form that satisfies regulatory review. It requires additional instrumentation and log retention that fraud teams often haven't built out, because the initial focus during PSD2 implementation was on getting SCA working, not on the audit infrastructure around exemption decisions.
Where cross-border transactions complicate the picture
For institutions operating across multiple EU jurisdictions, the TRA compliance picture is complicated by the fact that National Competent Authorities have different interpretations of some PSD2 provisions and different enforcement postures. The EBA (European Banking Authority) has issued opinions on several areas of ambiguity, but NCAs retain interpretive authority within their jurisdictions.
This creates a specific challenge for multinational PSPs: their fraud operations may be centralized, but their regulatory compliance obligations are country-specific. A single fraud rate that aggregates across jurisdictions may be below threshold when viewed in aggregate but above threshold in a specific country where that country's NCA is tracking it separately. Fraud teams serving multinational operations need jurisdiction-specific fraud rate tracking, not just global averages.
The SCA exemption stack and fraud team involvement
TRA is one of several SCA exemptions available under PSD2. Others include the low-value transaction exemption (under €30), merchant-initiated transactions, trusted beneficiary exemptions, and the recurring transaction exemption. Each has different conditions and different implications for fraud operations.
The trusted beneficiary list — where customers can designate merchants as trusted and thereby exempt their transactions from SCA — creates a fraud vector that most institutions haven't fully addressed. A compromised account that gains access to the trusted beneficiary list can add fraudulent payees to the whitelist, enabling subsequent fraudulent transactions to bypass SCA. Monitoring trusted beneficiary list modifications for anomalous behavior is a fraud operations responsibility, but many teams haven't explicitly built detection logic for it because the attack vector is relatively new.
Documentation requirements that fraud teams typically underestimate
Beyond the quantitative reporting, PSD2 compliance requires that PSPs maintain documented TRA methodology — the criteria and thresholds used to make exemption decisions, the data inputs used in risk assessment, the validation approach for confirming that the methodology is performing as intended. This documentation is subject to regulatory inspection.
In practice, "fraud team uses ML model to score transactions and applies exemption below threshold X" is not sufficient documentation. What inputs does the model use? How was the threshold determined? How is the model validated against current fraud patterns? How frequently is it retrained? What's the documented process for responding if the fraud rate approaches or exceeds the TRA threshold?
The teams that are most exposed here are those whose fraud models operate as black boxes maintained by third-party vendors with limited documentation of methodology. "We use Vendor X" is not a defensible answer during a regulatory review. The PSP is responsible for the compliance outcome, regardless of who built the technology.
PSD2 compliance for fraud teams isn't primarily a technology problem. It's a documentation, data, and process problem that requires explicit attention and ongoing maintenance — and it's not going to be resolved by simply running a fraud model.