PSD2 compliance and strong customer authentication in EU finance

At a glance

What this is: This is a PSD2 compliance explainer that centres on strong customer authentication, open banking access, and the operational obligations placed on EU and EEA payment organisations.

Why it matters: It matters because PSD2 shifts identity work into regulated payment workflows, forcing IAM teams to govern customer authentication, consented access, and fraud reporting as part of access control.

By the numbers:

• Organizations that fail to comply with PSD2 risk financial penalties of up to 4% of annual returns.

Context

PSD2 is the EU directive that governs electronic payment services across the EU and EEA. In practical identity terms, it pushes payment organisations to prove who is accessing accounts, under what consent, and through what authentication strength before a transaction or delegated request is allowed.

The control gap is not just technical API exposure. Once banks must open account access to third-party providers, access governance, customer authentication, and fraud reporting become part of the same operating model, especially where payment initiation and account information services are involved.

That makes PSD2 an IAM and governance problem as much as a payments one. The article frames compliance as a mix of authentication, consent, transparency, and regulatory registration, which is typical of open-banking obligations rather than an isolated edge case.

Key questions

Q: How should IAM teams govern customer consent in PSD2 open banking flows?

A: Treat consent as a governed delegation event, not a one-time checkbox. IAM teams should define which third-party providers may access which account functions, verify that the customer approved that scope, and preserve evidence of the approval. Without scope, provenance, and revocation, consent cannot support regulated open banking.

Q: Why does PSD2 require two independent authentication factors?

A: PSD2 uses two independent factors so a single compromise does not let an attacker complete a payment or account action. Independence matters more than the label of MFA. If one device, channel, or recovery path can satisfy both factors, the assurance model weakens and fraud resistance drops.

Q: What breaks when open-banking access is not tightly governed?

A: When consent, authentication strength, and API security are managed separately, third-party access can drift beyond its intended scope. That creates inconsistent assurance between direct and delegated journeys, weak auditability, and a higher chance that legitimate-looking access masks an abusive transaction path.

Q: What should organisations retain for PSD2 audit and fraud review?

A: Keep consent records, transaction provenance, third-party identity details, authentication evidence, and fraud handling records together. Those artefacts let compliance, security, and operations reconstruct what happened and prove that a payment or account action was properly authorised under PSD2.

Technical breakdown

Open banking APIs and third-party access control

PSD2 requires banks to expose account information and payment initiation capabilities through open APIs so authorised third-party providers can act on a customer’s behalf. That changes the control model from closed-channel banking to consented delegation. The security issue is not the API alone, but who can invoke it, under what entitlement, and how the bank verifies the request is within the customer’s approved scope. In IAM terms, this is delegated access with regulatory constraints, not simple application integration.

Practical implication: Practitioners need to treat API exposure as governed customer delegation, with explicit consent and entitlement boundaries.

Strong customer authentication and two independent factors

PSD2’s strong customer authentication requirement generally expects at least two independent factors from the categories of knowledge, possession, and inherence. The point is to reduce fraud risk in electronic transactions by making credential compromise alone insufficient. For IAM teams, the important detail is factor independence. If two factors are too tightly coupled, such as one device being used to satisfy both possession and approval, the control weakens materially. PSD2 therefore pushes authentication design closer to assurance engineering than to simple login hardening.

Practical implication: Map each payment journey to factor independence, not just MFA presence, before calling it PSD2-aligned.

Consent, reporting, and regulatory accountability

PSD2 combines customer consent, transparency obligations, fraud monitoring, and reporting into one compliance surface. That matters because authentication success does not end the governance requirement. Organisations still need to show what was authorised, what was executed, which party initiated it, and how fraud events are handled. For payment institutions, AISPs, and PISPs, the accountability chain extends beyond the login step into evidence, licensing, and recordkeeping. That is why PSD2 behaves like a governance framework in the identity layer.

Practical implication: Build audit evidence around consent, transaction provenance, and fraud reporting, not only around authentication logs.

Threat narrative

Attacker objective: The objective is to abuse delegated payment access or account information pathways to execute unauthorised financial activity while appearing legitimate.

1. Entry occurs through a payment or account-access request that reaches the bank through an open API exposed to a third-party provider.
2. Credential or consent abuse follows when the organisation cannot distinguish an authorised delegated request from an improperly scoped one.
3. Impact appears as unauthorised payment execution, account-data misuse, or reporting failure that triggers regulatory exposure.

Breaches seen in the wild

• Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

PSD2 turns customer authentication into a delegated-access control problem. The directive is not just asking for stronger logins. It requires organisations to decide how customer consent, third-party access, and transaction approval are connected inside the access model. That makes payment security dependent on identity governance, not only on fraud tooling. Practitioners should treat every PSD2 control as part of a regulated delegation chain.

Strong customer authentication fails when factor independence is treated as a checkbox. PSD2 expects at least two independent elements, which means the control only works if compromise of one element does not collapse the entire transaction path. If one device or one recovery flow can satisfy too much of the journey, the assurance level drops. Practitioners need to evaluate independence, not merely count factors.

Open banking widens the identity boundary beyond the bank's own perimeter. Third-party providers are now part of the access path, which means governance must extend to registration, consent scope, and transaction accountability. The practical consequence is that access review logic built only for internal users is too narrow. Practitioners should manage delegated access as an externalised identity lifecycle.

PSD2 creates a compliance stack where authentication, privacy, and fraud reporting are inseparable. The article explicitly links SCA, data confidentiality, GDPR alignment, and incident transparency. That combination means identity teams cannot treat payment security as a single control family. Practitioners should align authentication evidence with fraud monitoring and disclosure processes so compliance does not fragment across teams.

Regulated open banking exposes a governance gap around consent evidence. Customer permission is not meaningful unless the organisation can prove what was approved, who acted on it, and when the delegated action occurred. This is the kind of accountability problem that grows as APIs and payment initiation services scale. Practitioners need durable evidence trails, not just authentication events.

What this signals

Delegated access is now part of the payment control plane. PSD2 pushes IAM teams to govern third-party access as a regulated entitlement model, not as a loose integration pattern. That means consent, authentication, and revocation need to be managed as one lifecycle rather than separate controls.

Strong customer authentication only works when the assurance model is explicit. When teams cannot show why two factors are independent, they risk meeting the letter of the rule without preserving the intended fraud resistance. The operational test is whether a single compromise can still be blocked before payment execution.

Open banking expands the blast radius of identity failures. Once account access crosses organisational boundaries, weak delegation hygiene affects disputes, fraud handling, and regulatory evidence at the same time. The programme question is no longer whether SCA exists, but whether the full delegated-access chain is defensible.

For practitioners

• Map PSD2 journeys to explicit delegation scopes Document which account information and payment initiation actions each third-party provider may perform, then align those scopes to customer consent and business approval paths.
• Verify factor independence in strong customer authentication Test whether the two required authentication elements are operationally independent in recovery, device binding, and transaction approval flows.
• Separate authentication evidence from fraud evidence Keep records that show who consented, who initiated the action, what was executed, and how any suspicious or unauthorised payment was handled.
• Prepare regulator-facing audit trails for open banking Retain transaction provenance, consent records, and third-party access logs so licensing, incident review, and dispute handling can be supported together.

Key takeaways

• PSD2 makes payment identity a governance problem by tying customer authentication, delegated access, and consent to regulated banking workflows.
• The directive’s practical pressure point is not only login security but the evidence needed to prove who was authorised to act and on what scope.
• IAM teams should focus on factor independence, delegated-access boundaries, and audit trails that can survive regulatory review.

Key terms

• Strong Customer Authentication: A regulated authentication requirement that demands more than a single password or code. Under PSD2, it requires at least two factor types and must support the payment context, so the approval is tied to the specific transaction rather than a reusable login event.
• Third-Party Provider: A Third-Party Provider is an external organisation that accesses bank data or payment functions on behalf of a customer under an agreed consent model. In PSD2 contexts, this typically includes account information service providers and payment initiation service providers. Their access is limited by regulation, customer authorisation, and API controls.
• Open Banking Access: A model in which authorised third parties can access banking data through APIs with the customer’s consent. It expands the identity surface because partner credentials, consent tokens, and application entitlements must be governed as non-human identities.
• Payment Initiation Service: An open banking service that allows an approved third party to request payments from a user’s bank account. It is more sensitive than read-only data access because it directly affects funds movement and requires stronger accountability, validation, and revocation controls.

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 building or maturing an IAM programme, it is worth exploring.