Under the article’s summary of PSR and PSD3, accountability can shift to the PSP when it fails to use VoP properly, fails to monitor transactions, or does not block suspicious activity. If the provider’s controls were not applied correctly, liability is no longer just a customer issue.
When liability shifts from the customer to the PSP
Accountability depends on where the control failure sits. If the fraud was authorised by the customer but the PSP did not apply the required controls properly, the PSP can become accountable for the loss or part of it. The key question is not only who clicked approve, but whether the provider met its own duties around verification, monitoring, and intervention.
A useful way to think about this is that authorised fraud is not automatically a customer-only problem. If the PSP’s payment controls, fraud checks, or transaction monitoring were ineffective or not used as expected, the provider may have failed to meet the standard implied by the payment rule set and its own operating model.
That matters because PSP accountability is usually triggered by a control breakdown, not by the mere presence of a scam. A payment service that allows a suspicious transfer to proceed without proper confirmation, risk scoring, or step-up checks is exposing itself to the argument that the loss flowed from its process gap rather than the customer’s mistake.
What “failing to stop” usually means in practice
In authorised fraud cases, “failure” is usually about one of three things: verification was weak, monitoring was too passive, or the PSP ignored visible warning signs. If the PSP does not use authorisation models properly, the controls that should gate a high-risk payment can become a formality rather than a safeguard.
The same logic applies when the provider has the data but does not act on it. A PSP can see unusual destination accounts, abnormal velocity, mismatched payee details, or transaction patterns that depart from the customer’s baseline. If those signals are not monitored, triaged, or escalated, the control exists on paper but not in effect.
This is why liability discussions often focus on operating discipline. A provider that has the right policy but weak execution can still be treated as having failed to protect the customer, especially where a simple intervention could have interrupted the payment before funds left the system.
For PSPs, account ownership and lifecycle discipline also matter because weak entitlement hygiene can leave old access paths, stale rules, or unreviewed payment capabilities in place. IAM and IGA Basics is useful here because the same governance logic behind access review and entitlement control applies to payment decisioning and exception handling.
How PSP accountability is tested by regulators and dispute processes
In practice, accountability turns on evidence. Investigators will look at whether the PSP had appropriate controls, whether those controls were active at the time of the payment, and whether the provider responded to the transaction’s risk indicators in a defensible way. That is why auditability, transaction logs, and rule outcomes are so important.
The strongest cases against a PSP usually show a clear gap between what the provider said it would do and what it actually did. If the PSP promised risk monitoring, step-up checks, or beneficiary verification, then failure to apply those measures consistently can shift blame away from the customer.
Where authorised fraud is being analysed as a payment-risk issue rather than a pure customer-care issue, the dispute often turns on whether the provider’s design was capable of stopping a known scam pattern. That includes whether the PSP treated suspicious activity as a signal for intervention or merely as a post-event reporting item.
For a broader control lens, Role Mining and Role Design Guide helps illustrate how poorly governed permissions and decision paths create avoidable exposure, even when the process looks controlled from the outside.
Risk and Threat Considerations
Authorised fraud creates a narrow but important risk pattern: the payment is intentionally initiated by the customer, yet the PSP may still bear accountability if it had clear opportunities to detect or interrupt the scam. The practical danger is that weak monitoring, poor verification, or inconsistent exception handling turns a preventable fraud into a liability event for the provider.
Failure mechanism: The PSP lets a suspicious payment pass because risk signals are not operationalised, controls are bypassed, or the provider cannot show that verification and monitoring were applied at the time of the transfer.
Impact: The provider can face reimbursement exposure, supervisory criticism, and reputational damage, especially if the case suggests the PSP’s control environment was not strong enough to stop foreseeable authorised fraud.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Transaction monitoring and alert handling are central to stopping suspicious payments. |
| AC-6 — Least Privilege | Limits who can approve overrides or alter payment controls, reducing fraud exposure. | |
| IA-5 — Authenticator Management | Secure control of access to payment systems supports trustworthy verification and monitoring. | |
| Recommendation — Review payment alerts promptly and escalate suspicious activity for intervention. Restrict override and exception rights to the minimum necessary roles. Manage credentials tightly for staff and systems that operate fraud controls. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Management | Access governance supports who can approve, monitor, or bypass payment safeguards. |
| DE.CM-01 — Monitoring for Anomalies and Events | Suspicious payment behaviour depends on continuous monitoring and detection. | |
| Recommendation — Govern privileged access to payment and fraud-management functions. Monitor transaction patterns and flag anomalous payment behaviour. | ||
Practitioner Guidance
What to verify: Check whether the PSP can prove that transaction monitoring, beneficiary checks, and escalation steps were actually active for the affected payment path. If the evidence is only policy-level and not event-level, treat the control as unproven.
Decision rule: If a payment was high-risk and the provider had a realistic chance to stop it, focus first on control execution, alert handling, and intervention timestamps before debating whether the customer consented to the transfer.
What good looks like: A defensible PSP can show that suspicious transactions were screened, that unusual patterns triggered a response, and that staff or automated controls had a clear stop-or-hold authority when risk thresholds were met.
Practitioner takeaway: In authorised fraud disputes, accountability usually follows the control failure, not the scam label, so the decisive question is whether the PSP’s safeguards were real, active, and capable of interrupting the payment.
Related resources from NHI Mgmt Group
- Who is accountable when fraud network detection fails to stop serial abuse across the customer journey?
- How should organisations stop auto-sync from turning desktops into repositories of credentials?
- Who is accountable when an authorised fraud payment is not blocked?
- Who is accountable when economic deterrence fails against fraud operations?