PSD2 is the European Union’s second Payment Services Directive. It establishes rules for payment service providers, including security expectations for customer authentication and fraud reduction. The framework applies to organisations operating in the European Economic Area and shapes how payment access, transaction approval, and liability are handled.
Expanded Definition
PSD2 is a payments regulation, not an identity standard, but it strongly influences how payment access is authenticated, authorised, and monitored in the European Economic Area. In practice, security teams map PSD2 requirements to controls around strong customer authentication, transaction risk analysis, secure API access, and liability handling. Its most visible operational effect is that it pushes organisations toward stronger assurance for payment initiation and account access, especially where digital channels and delegated access are involved.
For NHI and agentic systems, PSD2 becomes relevant when software entities initiate payments, call banking APIs, or handle payment approval workflows. The term is often discussed alongside NIST Cybersecurity Framework 2.0 because both push organisations toward demonstrable governance, though PSD2 is narrower and sector-specific. Definitions vary across vendors when they describe “PSD2 compliance” as if it were a single technical control; in reality, it is a regulatory regime with implementation choices that differ by payment model and provider. The most common misapplication is treating PSD2 as a one-time authentication checklist, which occurs when teams ignore ongoing transaction monitoring and the role of machine-to-machine access in payment flows.
Examples and Use Cases
Implementing PSD2 rigorously often introduces friction in payment journeys, requiring organisations to weigh stronger fraud resistance against user experience and integration complexity.
- A payment service provider requires step-up authentication before an AI agent can submit a transfer on behalf of a customer, because the agent is acting as a delegated initiator rather than a passive system.
- An e-commerce platform routes recurring payments through risk-based decisioning so low-risk transactions can proceed while higher-risk events trigger stronger verification.
- A fintech secures API-based account access with scoped credentials and short-lived tokens, then aligns operational controls to the expectations described in the Ultimate Guide to NHIs.
- A bank reviews whether service accounts used by payment automation have excessive privileges, since PSD2-related workflows often depend on machine identities that are easy to over-extend.
- A compliance team tests whether a fraud signal can interrupt a payment approval path before settlement, using PSD2-oriented controls as part of broader access governance.
For implementation detail, organisations often pair PSD2 policy decisions with external guidance such as the NIST Cybersecurity Framework 2.0 and internal identity standards for services and APIs.
Why It Matters in NHI Security
PSD2 matters in NHI security because payment automation expands the blast radius of compromised credentials, over-privileged service accounts, and poorly governed API keys. NHIMG research shows that 79% of organisations have experienced secrets leaks, and that risk becomes especially consequential when those secrets can authorize payment actions or approve financial workflows. In PSD2 environments, a weak machine identity can create both fraud exposure and regulatory failure, particularly where customer-facing controls are assumed to cover backend automation.
Security teams also need to recognise that PSD2 obligations intersect with NHI lifecycle issues such as issuance, rotation, monitoring, and revocation. The regulation does not excuse insecure service-account design; it raises the bar for how payment access is controlled across humans, systems, and agents. Organisations typically encounter the real impact only after an unauthorized payment, disputed transaction, or failed audit, at which point PSD2 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 and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and EU-NIS2 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | PSD2-driven payment access depends on strong access control and authentication governance. |
| NIST SP 800-63 | AAL2 | PSD2's strong customer authentication concepts align with assurance expectations in digital identity. |
| NIST Zero Trust (SP 800-207) | IA-2 | PSD2 payment APIs benefit from continuous verification rather than implicit trust. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Payment automation often fails when secrets and service credentials are poorly managed. |
| EU-NIS2 | PSD2-linked payment services frequently sit inside critical digital operational resilience obligations. |
Align payment identity controls with resilience, incident handling, and supplier oversight requirements.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
