The European Union payment regulation known as PSD2, which modernised electronic payment rules and increased security expectations for account access and payment initiation. It also pushed providers toward secure APIs, stronger authentication, and controls that better support digital and cross-border payment activity.
Expanded Definition
Payment Services Directive 2, or PSD2, is the European Union rule set that reshaped electronic payment access by requiring stronger authentication, safer payment initiation, and more open account interfaces. In NHI and IAM discussions, PSD2 matters because it drives how systems authenticate, authorize, and expose payment functions through APIs rather than through manual, human-only workflows.
Definitions vary across vendors when PSD2 is discussed alongside open banking, but the regulatory core is consistent: regulated payment flows need stronger trust guarantees, and those guarantees must hold across banks, fintechs, and third-party providers. The most relevant operational lens is not simply customer login security, but the identity controls behind account access, consent, and delegated payment actions. That is why PSD2 is often discussed together with the NIST Cybersecurity Framework 2.0, which helps organisations map identity, protection, and resilience outcomes to regulated digital services.
The most common misapplication is treating PSD2 as only a customer authentication requirement, which occurs when teams ignore the API, consent, and machine identity controls that actually make payment access secure.
Examples and Use Cases
Implementing PSD2 rigorously often introduces integration and assurance overhead, requiring organisations to weigh broader payment access and interoperability against stronger identity verification and API governance.
- A bank exposes account information APIs to a licensed fintech, while enforcing strong customer authentication and scoped consent for every data access request.
- A payment service provider uses mutually authenticated service-to-service calls so that backend payment initiation can be traced, bounded, and revoked without weakening the customer journey.
- An enterprise reviews how delegated payment permissions are issued to software agents and third-party tools, aligning them with the lifecycle discipline described in Ultimate Guide to NHIs.
- A cross-border commerce platform separates user approval from machine execution, ensuring that payment initiation only occurs after policy checks, consent validation, and secure API exchange.
- A risk team uses PSD2 controls as a reference point for revisiting service-account exposure, then compares those findings with the visibility and rotation guidance in the Ultimate Guide to NHIs.
For teams building payment APIs, the practical challenge is not only regulatory compliance but also deciding where human approval ends and system-enforced trust begins, especially when third-party providers are part of the transaction path.
Why It Matters in NHI Security
PSD2 is relevant to NHI security because payment ecosystems depend on non-human identities to authenticate services, move requests between systems, and enforce policy at machine speed. If those identities are overprivileged, poorly rotated, or embedded in code, payment controls can be bypassed even when the customer-facing authentication flow appears compliant. NHIMG research shows that 97% of NHIs carry excessive privileges, and that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which makes payment APIs especially sensitive when secrets and service accounts sit behind regulated interfaces.
The security lesson is that PSD2 does not end at the login screen. It extends into the trust fabric connecting banks, payment processors, gateways, and third-party providers, where token handling, API authorization, and offboarding determine whether access remains controlled over time. Strong implementation also depends on secure secret storage, rotation, and the ability to revoke access when a provider relationship changes. The operational picture described in Ultimate Guide to NHIs shows why these controls matter across the full lifecycle, not just during onboarding.
Organisations typically encounter PSD2-related identity weaknesses only after a payment incident, service-provider failure, or audit finding, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the technical controls, and EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | PSD2 depends on access control, authentication, and authorization over payment APIs. |
| NIST Zero Trust (SP 800-207) | SP 5 | PSD2-style payment flows align with zero trust principles for continuous verification. |
| OWASP Non-Human Identity Top 10 | NHI-02 | PSD2 implementations often fail when secrets and service identities are poorly governed. |
| NIST SP 800-63 | AAL2 | PSD2's strong customer authentication expectations map to identity assurance concepts. |
| EU AI Act | Automated payment decisioning can intersect with regulated AI governance in payment workflows. |
Apply assurance levels consistently to payment access and require step-up authentication where risk rises.
Related resources from NHI Mgmt Group
- How should financial services teams secure AI agents that can call payment and customer systems?
- When do managed identity services help, and when do they create risk?
- How should security teams govern device-bound payment credentials in open finance?
- How should security teams handle weak credentials on exposed Linux services?
