Who is accountable when PSD2-related payment fraud occurs?

Accountability sits with the organisation that controls the authentication flow, the delegated access path, and the evidence needed to investigate the transaction. Regulators expect traceability across identity assurance, consent, and payment execution. If records are incomplete, the organisation is left unable to demonstrate compliance or explain the failure clearly.

Why This Matters for Security Teams

PSD2 fraud is not just a fraud ops problem. It is an identity, consent, and evidence problem that spans authentication, delegated access, and payment execution. Under PSD2 and related SCA expectations, accountability depends on which party controlled the flow and whether the event can be reconstructed after the fact. That makes access logs, consent records, and authentication telemetry part of the control surface, not just audit artifacts.

Security teams often miss that liability becomes hard to contest when authentication paths are fragmented across banks, payment service providers, and third-party integrations. The practical failure is usually not a single broken control, but weak traceability across the whole transaction chain. For broader NHI governance context, NHI Mgmt Group’s Ultimate Guide to NHIs shows how weak visibility into non-human identities magnifies downstream risk. The NIST NIST Cybersecurity Framework 2.0 reinforces that governance, detection, and recovery all depend on reliable evidence.

In practice, many security teams encounter disputed fraud only after the transaction has settled and the evidence trail is already incomplete.

How It Works in Practice

Accountability usually follows control, not blame. The organisation that owns the authentication step, the consent decision, and the payment initiation path is expected to prove what happened. In a PSD2 flow, that can include the account servicing payment service provider, the payment initiation service provider, or another delegated party, depending on the architecture and contractual chain. The key question is not who was most affected, but who had operational control at the time of the fraudulent event.

Practically, that means the organisation must retain evidence for:

• Strong customer authentication and the method used
• Consent capture and scope of delegated access
• Transaction details, timestamps, and risk signals
• Device, session, and API telemetry needed for reconstruction
• Exception handling, overrides, and failed step-up attempts

This is where identity governance overlaps with payment security. If credentials, tokens, or delegated access are reused across services, investigators may be unable to determine whether fraud came from credential abuse, consent manipulation, or a broken authorization path. The operational lesson from Ultimate Guide to NHIs is directly relevant: weak lifecycle control and poor visibility make it difficult to prove who controlled access at the moment of compromise. Current guidance suggests aligning payment controls with evidence retention practices already expected under frameworks such as the NIST Cybersecurity Framework 2.0, especially around detect, respond, and recover.

For one NHI-specific indicator of how often identity controls fail in the real world, NHI Mgmt Group reports that 79% of organisations have experienced secrets leaks, with 77% resulting in tangible damage.

These controls tend to break down when third-party payment flows rely on shared tokens, incomplete audit logging, or loosely defined delegation boundaries.

Common Variations and Edge Cases

Tighter authentication and evidence retention often increases operational overhead, requiring organisations to balance friction against dispute resilience. That tradeoff matters because PSD2 implementations vary widely across banks, fintechs, and outsourced service chains.

There is no universal standard for every edge case yet, but a few patterns recur. If a third-party provider initiates or modifies the payment, accountability may still sit with the organisation that exposed the delegated path and failed to constrain it. If fraud results from compromised credentials stored in scripts, CI/CD systems, or service integrations, the issue can resemble a non-human identity failure as much as a customer authentication failure. If logs do not show consent state, step-up decisions, and transaction binding, then the organisation may be unable to demonstrate that the flow met PSD2 expectations even if the technical authentication succeeded.

Teams should also be careful not to treat “the bank is responsible” or “the vendor is responsible” as universal answers. Best practice is evolving toward shared accountability with clear control ownership, contractual traceability, and runtime evidence. The safest interpretation is the one that can be defended during an investigation, not the one that sounds simplest on a slide.

Related resources from NHI Mgmt Group

• Who is accountable when a mobility platform is used for fraud or laundering?
• Who is accountable when identity fraud succeeds through weak verification?
• Who is accountable when P2P fraud slips through fragmented APAC controls?
• How should payment teams balance compliance and fraud controls in APAC P2P systems?