What are the signs that PSD2 implementations are being treated as a checkbox exercise rather than a security programme?

How to tell when PSD2 has been reduced to compliance theatre

Checkbox implementations usually show up when the programme is framed as a legal obligation to satisfy, not a security capability to improve. The tell is not whether controls exist, but whether they change how access is granted, how strong authentication is enforced, how payment journeys are authorised, and how exceptions are managed when the default process is inconvenient.

In practice, this often means teams add a new step for the audit trail while leaving the underlying system trust model intact. If the customer journey, API design, fraud controls, and account protection logic look almost unchanged after the PSD2 work is “done”, the implementation is probably compliance-led rather than security-led.

A useful check is whether the implementation improves security outcomes beyond the minimum legal wording. A security programme will usually leave visible traces in ISO/IEC 27002:2022 Information Security Controls style control thinking, such as stronger authentication design, clearer access accountability, and tighter handling of sensitive transactions. A checkbox exercise tends to stop at policy wording, screenshots, or a single control owner.

What shallow authentication and access redesign look like

One of the clearest warning signs is that strong customer authentication is treated as a bolt-on rather than a design constraint. If the implementation relies on a superficial second factor, but leaves brittle recovery flows, weak step-up decisions, or broad exception paths, the control may satisfy a review without materially reducing account takeover or payment abuse risk.

Another sign is poor alignment between authentication, authorisation, and transaction context. When teams enforce an authentication event but do not rework how sensitive actions are approved, limited, logged, and challenged, they often preserve the same exposure under a new compliance label. In security terms, the organisation has authenticated the user, but not meaningfully constrained what that session can do.

This is also where a control framework lens helps. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because it forces teams to think beyond one control family and into access control, authentication, auditability, and system integrity as related design choices. A weak PSD2 delivery usually improves one visible step while leaving the surrounding control environment unchanged.

What good PSD2 implementation changes in the operating model

A real security programme changes the operating model, not just the evidence pack. You should expect clearer ownership for authentication quality, transaction risk decisions, exception handling, and data protection, plus measurable changes in how often risky flows are challenged or denied. The programme should also influence system design choices such as API boundaries, customer journey fallback, and event logging.

The strongest indicator is whether teams can explain how PSD2 controls reduce specific business risks, such as account takeover, payment initiation abuse, or misuse of weak fallback processes. That explanation should be visible in architecture decisions and operational runbooks, not only in legal interpretation notes. If the only artefact is a compliance checklist, the programme is probably not being run as security work.

For broader governance alignment, NIST Cybersecurity Framework 2.0 is a useful reference because it pushes organisations toward governance, protection, detection, response, and recovery rather than isolated control completion. PSD2 work that matures into a security programme usually becomes visible across those functions, not just in a single authentication milestone.

Risk and Threat Considerations

When PSD2 is treated as a checkbox exercise, the main risk is false assurance: the organisation believes it has reduced payment and account risk while the underlying attack surface remains largely intact. That creates exposure to account takeover, abuse of weak fallback paths, and control bypass through flows that were never redesigned for security.

Failure mechanism: Teams implement the outward sign of compliance, such as a stronger login step or policy update, but leave permissive recovery, weak authorisation logic, and poorly governed exceptions in place. Attackers then target the preserved weak points rather than the visible control.

Impact: The organisation may pass a superficial review while still carrying materially elevated fraud, compromise, and customer trust risk. Over time, that gap also makes future remediation more expensive because the business has to undo brittle, compliance-shaped design decisions.

Practitioner Guidance

What to verify: Look for evidence that PSD2 controls changed system behaviour, not just documentation. The most useful proof is in transaction logs, exception rates, recovery paths, and architecture decisions that show sensitive actions are actually constrained.

Decision rule: If a control can be demonstrated only through policy text or a single audit screenshot, treat it as weak until you can show how it affects real access paths, authorisation decisions, and failure handling. If it changes customer and system behaviour under pressure, it is probably part of a security programme.

Practitioner takeaway: PSD2 maturity is visible when compliance requirements reshape how the product is built and operated, not when they merely appear in the control register.

Related resources from NHI Mgmt Group

• What are the signs that shift-left security is being treated as a checkbox rather than a working control?
• What are the signs that a security testing programme is becoming a checkbox exercise?
• What breaks when security culture is treated as a compliance exercise instead of a risk programme?
• How should security teams decide when identity management should be treated as a shared IAM control rather than a standalone programme?