PSD2 compliance now hinges on stronger authentication and fraud control

At a glance

What this is: PSD2 remains a live payment-security and fraud-governance issue, with the article arguing that SCA, exemption management, and auditability now matter as much as the rule set itself.

Why it matters: For IAM and security teams, the article matters because payment authentication, consent, and fraud controls increasingly depend on identity assurance patterns that overlap with customer verification, transaction trust, and regulated access decisions.

👉 Read Sift's PSD2 compliance checklist for payments and fraud prevention

Context

PSD2 is the regulatory layer that governs authentication and consent in many digital payment flows, so the core challenge is not understanding the directive itself but making its controls work across mobile, wallet, open banking, and merchant checkout paths. The identity angle is real: SCA, dynamic linking, and fraud monitoring all depend on how reliably a user or device can be authenticated at transaction time.

The article’s practical focus is compliance operations rather than legal theory. It treats PSD2 as an active control problem, especially where firms rely on exemptions, third-party payment interfaces, or fallback flows that can weaken assurance if they are not monitored consistently.

Key questions

Q: What breaks when PSD2 exemptions are used without strong fraud monitoring?

A: Exemptions stop being a friction-reduction tool and become a hidden trust channel. If fraud thresholds, issuer responses, and chargeback outcomes are not reviewed together, an organisation can keep approving high-risk transactions under a policy that no longer matches reality. The result is soft declines, higher fraud exposure, and weak evidence for regulators.

Q: Why do SCA and consent controls matter for open banking transactions?

A: Open banking relies on both authentication and transaction-specific consent. A user may authenticate successfully, but without dynamic linking and auditable consent records, that session does not prove the payment amount or payee were authorised. That gap turns a legitimate login into an insufficient control for payment integrity.

Q: How do you know if PSD2 controls are actually working?

A: Look for evidence across the whole payment path, not just approval rates. A healthy programme can show low soft-decline noise, stable fraud outcomes, documented exemption use, and consistent SCA decisions across checkout, wallet, and open banking flows. If any one channel behaves differently, the control model is uneven.

Q: Who is accountable when delegated payment authentication fails?

A: Accountability depends on where the authentication decision was made, who owned the exemption or delegation policy, and whether the evidence trail is complete. If a merchant, wallet, or issuer participates in the assurance chain, each party needs clear ownership for logging, review, and dispute handling under SCA governance.

Technical breakdown

Strong Customer Authentication and why payment flows break

Strong Customer Authentication, or SCA, requires at least two factors from possession, knowledge, or inherence for most remote payments. In practice, payment journeys fail when authentication is bolted on late, when device or app binding is inconsistent, or when the merchant and issuer disagree about whether an exemption applies. This is not just a checkout issue. It is an identity assurance issue because the system must prove both who or what initiated the payment and whether the transaction context matches the claim. The article’s emphasis on 3D Secure and open banking shows how authentication logic becomes part of the control plane, not a back-end afterthought.

Practical implication: map every payment path to an explicit SCA decision point and verify that fallback paths do not bypass authentication.

Exemptions, fraud thresholds, and transaction risk analysis

PSD2 exemptions exist to reduce friction, but they shift responsibility to fraud monitoring and policy discipline. Transaction Risk Analysis, low-value exemptions, merchant-initiated transactions, and whitelisting all depend on measured fraud rates and consistent issuer behaviour. The control problem is not exemption availability, it is exemption governance. If thresholds are not tracked carefully, an organisation may create a hidden trust gap where transactions are treated as low risk without evidence. This is where identity and fraud governance intersect: the system is deciding when an authenticated session can be trusted enough to skip extra challenge, which is a risk-based access decision in payment form.

Practical implication: tie every exemption path to a measured fraud threshold, periodic review, and a documented approval trail.

Dynamic linking, APIs, and open banking trust

Dynamic linking binds the authentication result to the specific amount and payee, which is critical in account-to-account payments where trust can otherwise be reused across transactions. For open banking, the security boundary extends into APIs, certificates, and consent handling for account information and payment initiation services. If those controls are weak, a valid login does not mean a valid transaction. This is a familiar identity lesson: session trust is not transaction trust. The article correctly treats encryption, certificates, and consent records as part of the compliance baseline, because open banking security fails when identity proof and payment intent are not cryptographically tied together.

Practical implication: enforce dynamic linking and audit consent records for every A2A path, including third-party payment initiation services.

Threat narrative

Attacker objective: The attacker aims to move money through a payment path that the organisation treats as trusted enough to skip stricter verification.

1. Entry occurs through a payment flow that relies on weak or inconsistent authentication, such as an exempted checkout, a compromised mobile session, or a poorly controlled open banking interface.
2. Escalation happens when attackers exploit trusted payment paths, reuse consent, or abuse exemption logic to push transactions without the expected SCA challenge.
3. Impact is fraudulent authorisation, soft-decline evasion, or unauthorised payment initiation that bypasses the intended assurance model.

NHI Mgmt Group analysis

PSD2 compliance is now an identity governance problem, not just a payments-rule problem. The article shows that authentication, consent, and transaction binding are the real control surfaces. That means payment teams, IAM teams, and fraud teams have to share a common assurance model rather than manage separate checkpoints. Practitioners should treat PSD2 as a transaction identity framework, not just a legal checklist.

Exemption governance is the named risk hidden inside most PSD2 programmes. The dangerous assumption is that a low-friction path remains low risk once it has been approved. In reality, exemptions become a governance debt if fraud thresholds, challenge outcomes, and issuer behaviour are not reviewed together. Practitioners should define clear ownership for exemption policy and evidence.

Dynamic linking is the clearest boundary between authentication and transaction trust. If the amount and payee are not cryptographically bound to the authentication event, then a valid session can be reused in ways the security model never intended. This matters for open banking, A2A, and wallet-based flows alike. Practitioners should treat dynamic linking as a control requirement, not a technical option.

PSD3 will likely increase the pressure on evidence, not reduce it. The article’s forward look suggests more scrutiny around identity verification, fraud reporting, and supervision of non-bank payment providers. That means governance teams should expect more operational proof, not just policy declarations. Practitioners should prepare to show how authentication decisions are made, monitored, and audited end to end.

What this signals

Exemption governance becomes the pressure point as payment ecosystems add more wallets, open banking integrations, and merchant-initiated flows. If the control model cannot prove when friction was removed and why, compliance drift will show up first as weak evidence and then as fraud leakage. The programme answer is to treat every exemption as a monitored identity decision, not a convenience setting.

Payment security teams should expect regulators to ask for end-to-end proof, not policy intent. That means authentication logs, consent trails, fraud outcomes, and exception handling all need to line up across channels. The more payment journeys depend on third parties, the more the organisation has to prove that identity assurance remained intact at the point of transaction.

For practitioners

• Map every payment journey to a distinct authentication rule Document which checkout, wallet, open banking, and merchant-initiated flows require SCA, which qualify for exemptions, and which fallback paths exist when 3D Secure or app-based challenges fail. Make sure the policy is written at the transaction path level, not just the channel level.
• Track exemption performance against fraud thresholds Measure challenge rate, approval rate, soft decline rate, chargeback rate, and fraud rate for every exemption type, then review those metrics against the thresholds that justify continued use.
• Bind consent and payment intent together For account-to-account and open banking flows, require dynamic linking so the authentication event is tied to the exact amount and payee, and retain consent records in an auditable form.
• Harden API and certificate controls for payment access services Use strong transport security, certificate management, and access logging for account information and payment initiation services so that a valid API session cannot be mistaken for a valid transaction.
• Create an audit trail for every SCA decision Store the rationale for each challenge, exemption, and fallback decision so compliance, fraud, and security teams can reconstruct why a transaction was approved or stepped up.

Key takeaways

• PSD2 compliance is really about controlling authentication, consent, and transaction trust across every payment path.
• Exemptions reduce friction only when fraud thresholds, issuer behaviour, and audit evidence are managed together.
• For IAM and security teams, the decisive question is whether each payment decision can be proven after the fact.

Key terms

• 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: Transaction risk is the likelihood that a payment, deposit, withdrawal, or transfer is abusive, compromised, or inconsistent with normal behaviour. It is distinct from login risk because a legitimate session can still produce fraudulent or non-compliant financial activity.
• Dynamic Linking: A transaction integrity control that binds authentication to the payment amount and payee. If either changes, the authentication code is no longer valid, which helps stop substitution attacks and prevents a legitimate approval from being reused for a different transfer.
• Soft Decline: A payment rejection caused by missing or insufficient authentication rather than a permanent card or account problem. Soft declines are operationally useful because they signal where SCA logic is missing or incomplete, and they often expose whether fallback paths are wired correctly.

What's in the full article

Sift's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance on implementing Strong Customer Authentication across card-not-present, wallet, and open banking flows
• Practical advice on using PSD2 exemptions without drifting outside fraud thresholds or audit expectations
• Detailed handling patterns for soft declines, mobile challenge drop-off, and issuer-side authentication failures
• A checklist for preparing for PSD3 and the UK’s evolving payment-services regime

👉 Sift's full article adds the checklist detail on SCA, exemptions, audit trails, and PSD3 readiness.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, IAM, and identity lifecycle foundations. It helps practitioners connect identity assurance to broader security and compliance programmes.