Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

PSD2, SCA, and open banking: what IAM teams need to change


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 12212
Topic starter  

TL;DR: PSD2 requires EU and EEA payment organisations to open APIs to third-party providers, enforce strong customer authentication with two independent factors, and improve fraud transparency and reporting, according to 1Kosmos. For identity teams, the directive turns customer authentication, delegated access, and consent handling into governance problems, not just payment controls.

NHIMG editorial — based on content published by 1Kosmos: PSD2 compliance and strong customer authentication in EU finance

Questions worth separating out

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.

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.

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.

Practitioner guidance

  • 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.
  • 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.
  • 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.

What's in the full article

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

  • How PSD2's Strong Customer Authentication requirements map to practical authentication workflows
  • The role of open APIs, TPP registration, and consent handling in day-to-day implementation
  • 1Kosmos's product-specific discussion of identity proofing, FIDO2 authentication, and integrations
  • Compliance considerations for banks, payment institutions, and fintechs working across EEA jurisdictions

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

PSD2, SCA, and open banking: what IAM teams need to change?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 11787
 

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.

A few things that frame the scale:

A question worth separating out:

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.

👉 Read our full editorial: PSD2 compliance and strong customer authentication in EU finance



   
ReplyQuote
Share: