Banks should treat PSD2 as an architecture and governance change, not just a compliance update. They need to expose payment and account data through controlled interfaces, strengthen customer authentication, and redesign risk controls for third-party access. The practical goal is to preserve trust while supporting new payment initiation and account information services without creating weak links in transaction flow.
How PSD2 Changes the Authentication Boundary
PSD2 does not remove authentication, it redistributes it across a more complex trust chain. The bank remains accountable for customer authentication quality, but third-party providers can now initiate access through regulated interfaces. That means the bank has to treat authentication as a policy decision tied to channel, consent, transaction context, and the identity of the requesting party, not as a single login event.
In practice, strong customer authentication should be designed for step-up moments, not forced uniformly across every interaction. The challenge is to distinguish low-risk account information access from payment initiation and from session reuse, because each one carries a different fraud profile and a different user-experience trade-off.
Banks also need to make authentication resilient to integration failures. If a third-party route fails open, retries incorrectly, or reuses stale sessions, the bank can end up with a control gap even when the front-end authentication flow looks sound.
Authorization Must Be Scoped to Consent, Purpose, and Payment Context
Under PSD2, authorization is no longer just “is this user logged in”, it is “is this third party allowed to do this exact action for this exact customer under this exact consent”. That shifts the bank toward fine-grained authorization, where consent scope, account scope, payment amount, payee, and expiry all matter.
The best designs separate authentication from authorization very explicitly. A third party may authenticate successfully but still be denied payment initiation if the consent is missing, expired, overbroad, or inconsistent with the transaction being requested. Banks should assume that authorization failures are safety controls, not just user friction.
Scope design matters because overly broad permissions create hidden blast radius. If consent tokens or delegated access can be replayed across products, environments, or channels, the bank has effectively weakened the original regulatory safeguard.
Building Third-Party Access Without Weakening the Control Plane
The operational problem is not whether access is allowed, but how the bank keeps it constrained and observable. PSD2 pushes banks toward API-mediated access, which means the control plane must include interface governance, third-party onboarding, certificate or client credential management, auditability, and revocation paths that work quickly when a provider is compromised or a customer withdraws consent.
This is where architecture and governance meet. If the bank relies on one-off partner exceptions, manual whitelisting, or inconsistent API policy enforcement, the PSD2 model starts to behave like shadow integration. A strong design keeps the same authorization logic across all channels, with clear lineage from customer consent to API request to executed payment.
From a practitioner perspective, the goal is to make delegated access precise enough that the bank can prove who asked for what, under which consent, and with what outcome. That is the difference between a scalable open-banking model and a collection of fragile partner integrations.
Risk and Threat Considerations
PSD2 expands the number of actors and interfaces that can reach account and payment functions, so the main risk is not only fraud but control dilution. The more third parties and delegated flows you support, the more important it becomes to contain replay, token abuse, consent drift, and weak revocation handling.
Failure mechanism: Delegated access can outlive the customer intent or exceed the originally approved scope if consent records, token lifetimes, revocation, and transaction validation are not tightly bound together. A compromise at the third party, or a flaw in the bank's API policy, can then turn an allowed integration into an unauthorized payment path.
Impact: The bank can suffer unauthorized payments, account data exposure, regulatory non-compliance, and a loss of customer trust that is difficult to repair because the weakness sits in the delegated access model itself, not just in one compromised login.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Payment auth under PSD2 depends on strong customer authentication and step-up assurance. |
| Recommendation — Use assurance levels and phishing-resistant authenticators for higher-risk payment actions. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | PSD2 requires fine-grained enforcement of delegated payment and account access. |
| IA-5 — Authenticator Management | Banks must manage credentials, tokens, certificates, and revocation for third-party access. | |
| Recommendation — Enforce scoped access rules for each third-party request and payment action. Rotate, bind, and revoke authenticators and tokens on a strict lifecycle. | ||
| OWASP ASVS | V10 — OAuth and OIDC | PSD2 API access commonly relies on OAuth-style delegated authorization flows. |
| V8 — Authorization | PSD2 consent and scope checks map directly to fine-grained authorization decisions. | |
| V6 — Authentication | Customer and partner authentication quality determines whether payment initiation is trustworthy. | |
| Recommendation — Validate delegated authorization flows and token handling for third-party access. Enforce per-action authorization based on consent, scope, and transaction context. Require strong, contextual authentication for customer and third-party sessions. | ||
Practitioner Guidance
What to prioritise: Put consent lifecycle, transaction-scoped authorization, and revocation reliability ahead of cosmetic API expansion. If a bank can authenticate customers but cannot reliably prove that every delegated action matches current consent, the control design is incomplete.
What to verify: Test the full path from third-party onboarding to token issuance, request validation, payment execution, and withdrawal of consent. The critical question is whether the bank can stop access quickly and consistently when a provider is compromised, a customer objects, or a token is replayed.
What good looks like: A payment request is accepted only when the requester, consent, transaction details, and channel policy all line up, and the resulting decision is fully auditable. That is the practical standard for PSD2-era control strength.
Practitioner takeaway: Treat PSD2 as delegated-access governance with transaction-grade controls, because the real security test is not whether third parties can connect, but whether the bank can bound, explain, and revoke every action they take.
Related resources from NHI Mgmt Group
- What breaks when customers and third parties can access bank data without robust authentication controls?
- What is the difference between API access and screen scraping under PSD2 payment account rules?
- How should organisations adapt data-sharing governance when users, third parties, and public bodies gain broader access to device-generated data under the EU Data Act?
- What are the implications of using OAuth tokens in third-party integrations?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
