PSD3 and PSR make transaction proof harder, not easier

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Forter's report: PSD3 and PSR raise the bar for proving transaction legitimacy and make fraud controls, exemptions and liability handling materially stricter.

Why it matters: Payment and IAM practitioners need to understand how the new evidence standard changes dispute handling, customer friction and the governance of authentication decisions.

Context

PSD3 and PSR change the governance model for payment authentication by separating proof of identity from proof of authorization. In practice, that means a successful challenge response or customer sign-in no longer settles who is responsible when a payment is disputed, especially where acquirers and merchants sit between the payer and the bank.

The regulatory package also narrows the room for blanket exemptions and pushes more responsibility into transaction monitoring and dispute evidence. That matters for payment operations, fraud teams and identity controls because authorization decisions now depend on the quality of the signals behind the transaction, not just the presence of SCA.

Key questions

Q: Did PSD3 make SCA enough to prove payment authorisation?

A: No. Strong Customer Authentication proves the payer was authenticated, but it does not by itself prove that a specific payment was authorised or that the merchant had valid consent evidence. Payment authorisation still depends on records such as authentication logs, payer device or channel data, and transaction context showing why a payment was approved.

Q: Why do transaction risk exemptions create liability under PSD3?

A: They create liability because a merchant or payment provider that relies on a transaction risk exemption is asserting that the payment was low risk and could be processed without full authentication. If fraud follows, the party that applied the exemption may have to justify why an exemption was justified, using risk scoring, fraud monitoring and transaction evidence.

Q: How should merchants govern payment authentication evidence?

A: Merchants should treat payment authentication evidence as governed records, with controls for capture, retention, integrity and retrieval across checkout, issuer response and fraud review. Transaction signals, risk scoring and challenge outcomes should be linked to each payment so the merchant can reconstruct authorisation, defend disputes and explain the basis for exemptions or step-up authentication.

Q: What happens when acquirers become liable for weak fraud monitoring?

A: They usually tighten controls, because liability for weak fraud monitoring pushes acquirers to demand better transaction screening, stronger exception handling and clearer evidence of merchant checks. A more conservative posture typically means stricter exemption use, closer review of fraud patterns and faster escalation when monitoring gaps or abnormal payment behaviour appear.

Technical breakdown

Why SCA no longer settles authorization disputes

Strong Customer Authentication confirms that a payer completed an authentication step, but it does not by itself prove that a specific transaction was authorised in the legal or operational sense. Under the PSD3 and PSR model, the burden moves toward evidence that the transaction context, risk controls and monitoring all support the approval decision. That creates a sharper distinction between identity proof, session authentication and transaction legitimacy. For merchants and PSPs, the technical problem is not whether a customer authenticated, but whether the full payment event can be defended with transaction-level telemetry and policy records. See the Authorisation Models Guide.

Practical implication: Treat SCA as one input to dispute evidence, not as the evidence itself.

How liability shift changes acquirer and PSP behaviour

A liability shift changes incentives in the payment chain. When acquirers can be liable if they cannot show monitoring or review before approval, the approval path becomes more conservative and evidence-driven. That often means stricter routing rules, higher rejection thresholds and more checks before risky transactions clear. In effect, the control surface moves upstream from post-transaction dispute handling to pre-authorisation decisioning. This is a governance problem as much as a fraud problem, because the party making the decision must now be able to prove why the decision was reasonable at the time.

Practical implication: Build approval logic that can be justified after the fact, not just optimised for conversion.

Why TRA exemptions become a governance control, not a convenience rule

Transaction Risk Analysis exemptions are no longer just a way to reduce customer friction. Under a stricter regime, they become a controlled exception process that depends on demonstrable fraud prevention capability, not only on aggregate fraud rates. That shifts the technical challenge to exception governance: how exemptions are requested, qualified, logged, reviewed and revoked when a PSP’s risk posture changes. For subscription merchants and recurring flows, the key issue is that exemption policy can become dynamic and inconsistent across providers, which makes static rules brittle. See the PSD2/PSD3 Strong Customer Authentication Guide.

Practical implication: Govern TRA exemptions like an exception workflow with audit evidence and review triggers.

NHI Mgmt Group analysis

PSD3 turns payment authentication into an evidence problem. The central shift is not that identity checks disappear, but that they stop being enough on their own. Payment governance now has to prove the legitimacy of the transaction event, not merely that a customer passed a challenge. For practitioners, that means the control design must move from single-step authentication assurance to defensible transaction evidence.

Liability shift will change risk appetite faster than most merchants expect. When acquirers and PSPs can be on the hook without strong proof of monitoring, they will rationally become more conservative. That does not just affect fraud teams; it affects product, conversion and dispute operations. The likely outcome is uneven authorisation behaviour across providers, so merchants need governance that can absorb that variability.

TRA exemptions become an exception-management discipline. Exemptions are no longer a background setting that can be tuned once and forgotten. They become a policy boundary that needs evidence, review and change control. Merchants that treat exemption handling as static configuration will struggle when PSPs tighten thresholds or change posture.

Authorization evidence will matter more than challenge success. That creates a new operational concept for payments teams: proofable authorisation posture, meaning the ability to show why a transaction was approved, not just that it was authenticated. This is the governance layer PSD3 and PSR are implicitly demanding, and it should shape how disputes, logs and fraud signals are retained.

From our research library:

• U.S. fraud losses are projected to reach $40 billion by 2027.

What this signals

Proofable authorisation posture: payment teams will need to show how a transaction was justified, not just that the customer authenticated. That changes the design goal for logging, retention and dispute workflows, because evidence quality becomes part of the control itself.

PSPs that tighten exemptions or change risk appetite will force merchants to think in provider-specific decision paths rather than one universal authorisation model. That pushes operational governance toward routing resilience, exception review and evidence portability across payment flows.

For practitioners

• Separate authentication from authorization evidence Record the transaction signals, decision inputs and risk checks that justify approval, so SCA is only one part of the dispute record.
• Rework exemption governance for TRA decisions Define who can grant exemptions, what evidence is required, how often the policy is reviewed and when exemptions are revoked.
• Validate acquirer and PSP liability assumptions Map which party holds evidence for monitoring, challenge and approval across each payment flow, then close any documentation gaps.
• Reduce dependency on a single processor Use multiple PSPs where practical so one provider's risk posture does not dictate every authorisation decision or exemption outcome.
• Retain dispute-ready telemetry Keep behavioral, device and network signals long enough to support chargeback and fraud claims when SCA alone is insufficient.

Key takeaways

• PSD3 and PSR raise the bar from authentication success to defensible payment approval, which changes how dispute evidence is built.
• The strongest operational impact is likely to be more conservative provider behaviour, especially where exemption handling is weak or poorly documented.
• Merchants and PSPs will need evidence-rich authorization governance if they want to preserve conversion without increasing liability.

Related NHI Mgmt Group resources: Authorisation Models Guide · PSD2/PSD3 Strong Customer Authentication Guide · Financial Services Identity Security Guide

Key terms

• Acquirer Liability Shift: Acquirer liability shift is a payment rule that moves financial responsibility for certain fraudulent card transactions from the issuer to the acquirer or merchant side. It applies when the acquirer fails to meet required authentication, fraud screening or transaction control conditions, so disputes and chargeback losses follow the weaker control point.
• Strong Customer Authentication: A regulated authentication requirement that demands more than a single password or code. Under PSD2, it requires at least two factor types and must support the payment context, so the approval is tied to the specific transaction rather than a reusable login event.
• Transaction Risk Analysis (TRA): Transaction Risk Analysis is a risk-based identity verification check used during payments and account activity to estimate the chance that a transaction is fraudulent or otherwise suspicious. It typically evaluates signals such as device, location, behaviour and transaction history, then adjusts authentication or review requirements accordingly.
• Merchant-Initiated Transaction: A merchant-initiated transaction is a payment triggered by a merchant after an initial customer authentication, such as a subscription renewal. Under SCA, the buyer generally needs to authenticate only once, but the merchant must still handle the transaction in a way that fits payment and regulatory rules.

Deepen your knowledge

NHI Foundation Level course covers NHI governance, IAM and secrets management, with a practical grounding in how identity controls support security decisions. It is a fit for practitioners who need to connect access governance to broader security operations.