PSD2 compliance and strong customer authentication in EU finance

At a glance

What this is: PSD2 is the EU payments directive that reshapes authentication, open API access, and third-party provider governance for financial services.

Why it matters: It matters to IAM practitioners because PSD2 pushes customer authentication, delegated access, and fraud handling into the same control plane that also governs identity assurance and lifecycle risk.

👉 Read 1Kosmos's analysis of PSD2 compliance and strong customer authentication

Context

PSD2 is a payment security and access governance problem, not just a banking regulation. It requires organisations to prove who is acting, who is allowed to act on behalf of a customer, and how third-party access is controlled across open APIs and payment journeys.

For IAM and security teams, the practical issue is that consent, authentication strength, and delegated access now have to work together. That puts pressure on customer identity proofing, step-up authentication, API authorisation, and the monitoring of third-party providers that touch payment data.

Key questions

Q: How should organisations implement strong customer authentication for PSD2?

A: Organisations should map transaction risk to authentication strength and prove that the factors used are independent and appropriate for the payment action. The control is not simply MFA at the login screen. It is assurance that the authenticated identity, device, and transaction context together satisfy the PSD2 requirement before payment execution.

Q: Why does PSD2 make third-party provider access a governance issue?

A: PSD2 gives third-party providers access to customer data and payment functions through open APIs, which means the organisation must govern delegated access, not just internal user access. Consent is necessary, but it is not enough. Teams also need scope control, monitoring, and revocation so the provider's authority stays aligned to the approved purpose.

Q: What breaks when API access under PSD2 is not tightly scoped?

A: When API access is not tightly scoped, organisations lose clarity on which provider is acting, which customer consent applies, and whether the request matches the approved payment purpose. That weakens fraud detection, auditability, and dispute resolution. In practice, the business then struggles to prove that a transaction was properly authorised.

Q: Who is accountable when PSD2-related payment fraud occurs?

A: Accountability sits with the organisation that controls the authentication flow, the delegated access path, and the evidence needed to investigate the transaction. Regulators expect traceability across identity assurance, consent, and payment execution. If records are incomplete, the organisation is left unable to demonstrate compliance or explain the failure clearly.

Technical breakdown

Strong customer authentication and identity assurance

PSD2's strong customer authentication requirement is built around two independent factors, which is meant to reduce fraud when payment activity is initiated electronically. In practice, this moves the control question from simple login success to whether the authentication event is strong enough for the risk of the transaction. For financial organisations, that means assurance levels, device binding, and proofing quality matter as much as the authentication prompt itself. The directive also creates an operational link between customer identity, transaction context, and downstream payment execution.

Practical implication: map transaction risk to authentication strength, not just to a generic MFA policy.

Open banking APIs and third-party provider access

PSD2 requires banks and related institutions to expose APIs so third-party providers can retrieve account information or initiate payments with consent. That makes the API layer an identity boundary, because the organisation is no longer only authenticating its own users. It must also authorise external service providers, validate their roles, and control what they can do after consent is granted. The governance challenge is therefore not only access issuance but also delegated access scope, revocation, and transaction integrity across shared services.

Practical implication: treat third-party API access as a governed identity relationship with explicit scope and revocation controls.

Fraud reporting, transparency, and liability controls

PSD2 links payment security to transparency, fraud monitoring, and customer protections, including reduced liability for unauthorised payments in some cases. That changes the identity programme's responsibilities because detection, incident reporting, and evidence retention become part of the compliance story. Organisations need to know which authentication events were used, which provider initiated the action, and whether the request matched the consented purpose. Without that evidence chain, it becomes difficult to prove compliance or investigate disputed transactions.

Practical implication: retain authentication and delegation evidence long enough to support fraud review and accountability.

NHI Mgmt Group analysis

PSD2 turns customer authentication into a governance problem, not just an assurance problem. Strong Customer Authentication is about more than adding factors at login. It forces security teams to decide whether the identity event is strong enough for a payment action, which means assurance, transaction context, and consent now have to be governed together. Practitioners should treat authentication policy as part of payment authorization design, not as a front-end control.

Open banking creates delegated access risk that looks like NHI governance in a regulated form. Third-party providers become durable actors in the payment ecosystem, with access that is created, scoped, monitored, and eventually revoked. That is structurally similar to machine and service-account governance, even if the legal wrapper is different. The important point is that consent does not remove the need for lifecycle control. Practitioners should govern third-party access as a lifecycle process, not a one-time approval.

PSD2 exposes the gap between access granted and access understood. Many organisations can expose APIs faster than they can track which provider is calling, what scope was granted, and which identity evidence supports the transaction. That is where fraud reporting, auditability, and identity assurance converge. The framework is less forgiving where evidence is incomplete, so practitioners need traceable identity-to-transaction records that survive dispute handling and regulatory review.

Identity assurance, API governance, and fraud monitoring now form one control chain. PSD2 does not let teams manage authentication, delegated access, and incident evidence as separate programmes. When one part is weak, the others inherit the failure. That is why payment security leaders should align IAM, API security, and fraud operations around the same trust model and the same accountability trail.

Consent without lifecycle control is the hidden PSD2 failure mode. The directive assumes that third-party access can be granted for a valid purpose and then constrained over time. That assumption fails when organisations lose sight of who has access, why they still have it, and whether the consented scope still matches the live relationship. The implication is that delegated access governance must be continuous, not event-driven.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, and 38% have no or low visibility, according to The State of Non-Human Identity Security.
• That visibility gap matters because 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, according to The State of Non-Human Identity Security.
• For deeper lifecycle guidance, review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs and align delegated access reviews with consent revocation.

What this signals

Consent-based access only works when the organisation can still see it. PSD2-style delegated access models and OAuth-connected ecosystems both fail when visibility drops below the level needed for revocation, review, and investigation. A programme that cannot identify every third-party actor in scope will struggle to prove that access stayed within the approved purpose.

Third-party access governance is converging with NHI lifecycle management. The same operational questions keep appearing across payment APIs, service accounts, and workload identities. Who created the access, what scope was granted, when does it expire, and how is it revoked when the relationship changes? Those questions belong in the IAM operating model, not in a separate compliance checklist.

For practitioners

• Map PSD2 controls to identity assurance levels Tie payment risk classes to proofing strength, authentication factor independence, and step-up requirements for high-risk transactions. Use assurance evidence to show why a specific transaction path met the PSD2 bar.
• Govern third-party provider access as a lifecycle Track onboarding, consent scope, API permissions, and revocation for every third-party provider that can touch accounts or initiate payments. Review stale access and confirm that the approved purpose still exists.
• Retain transaction evidence for fraud and dispute handling Keep authentication events, provider identifiers, consent records, and payment logs together so investigators can reconstruct who acted, under what authority, and on which data.
• Align API security with IAM and fraud monitoring Make API authorisation, customer authentication, and fraud detection part of one operating model. That prevents gaps where a valid login masks an invalid or over-scoped payment action.

Key takeaways

• PSD2 makes authentication, delegated access, and fraud evidence part of one governance chain rather than separate controls.
• Open banking increases the number of external identities that must be scoped, monitored, and revoked with discipline.
• Teams that cannot trace consent to transaction execution will struggle to prove compliance when disputes or fraud occur.

Key terms

• Strong Customer Authentication: A higher-assurance authentication requirement that uses at least two independent factors to confirm a customer before a payment is approved. In PSD2 contexts, it is meant to reduce fraud by tying authentication strength to transaction risk, not simply by adding another login step.
• Third-Party Provider: An external regulated organisation that can access payment accounts or initiate payment services on a customer's behalf under PSD2. The access is consent-based, but it still requires strict scope, monitoring, and revocation because the provider becomes part of the organisation's live trust boundary.
• Open Banking API: A published application interface that allows approved external services to interact with account data or payment functions. In identity terms, it creates a governed delegation path, so authorisation, consent, and auditability must be as strong as the authentication used to access the interface.
• Identity Assurance: The degree of confidence that an identity claim is valid for the action being taken. In payment environments, assurance is not static. It must be evaluated against the transaction, the channel, the device, and the delegated access path before execution is allowed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by 1Kosmos: PSD2 compliance and strong customer authentication in EU finance. Read the original.