Who is accountable when an authorised fraud payment is not blocked?

Why This Matters for Security Teams

When an authorised fraud payment is not blocked, accountability usually follows the control failure, not just the business outcome. Under payment services rules, the question is whether the payment service provider applied the required checks, monitored the transaction, and acted on risk signals with evidence. That means investigators need proof of what happened, when it happened, and which control was expected to stop it. The issue is operational as much as legal.

This is why teams treat payment controls as a chain of execution, not a single gate. If verification of payee, transaction monitoring, or suspicious payment intervention is weak, accountability can shift toward the party that owned that control. The same pattern appears in identity-driven incidents such as the Schneider Electric credentials breach, where weak control execution becomes the real story after the event. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which shows how often control owners cannot even prove what their systems did. In practice, many security teams encounter accountability disputes only after the fraud loss has already been booked, rather than through intentional control testing.

How It Works in Practice

Accountability starts with mapping the payment flow to named control owners. In a well-run environment, each step has an evidence trail: who approved the payment, whether payee verification was performed, what the fraud engine saw, and whether the system blocked, delayed, or released the transfer. The practical question is not only "was the payment authorised?" but "did the PSP perform the controls it was expected to perform?"

For security and risk teams, this means building a record that can stand up to post-incident review. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces governance, monitoring, and response as separate obligations rather than a single policy statement. The same logic applies to payment fraud: control ownership, logging, alert triage, exception handling, and escalation thresholds should all be measurable. The Ultimate Guide to NHIs shows why this matters in adjacent control environments too, because weak visibility and poor credential lifecycle management make it hard to prove whether a system behaved as intended.

• Assign a named owner for verification of payee, monitoring, and block or release decisions.
• Log the exact reason codes, timestamps, and operator actions tied to each control step.
• Test whether alerts actually trigger intervention, not just dashboard notifications.
• Retain evidence so liability reviews can distinguish a policy gap from an execution failure.

Where organisations get this wrong is assuming that fraud control is satisfied by having a policy, when accountability turns on whether the control operated correctly under real transaction conditions. These controls tend to break down when payment volumes spike and exceptions are processed manually because human review is too slow to stop fast-moving fraud.

Common Variations and Edge Cases

Tighter fraud controls often increase friction, so organisations must balance customer experience against loss prevention and evidentiary strength. There is no universal standard for this yet, especially where instant payments, mule account detection, and authorised push payment fraud overlap.

One edge case is shared accountability. A bank, payment processor, and initiating service provider may each own different parts of the control chain, so liability depends on which party failed its duty and whether the failure was technical, procedural, or evidential. Another complication is false positives: a system that flags too aggressively may preserve liability defences but disrupt legitimate payments. Current guidance suggests documenting those trade-offs explicitly rather than treating them as informal operating choices. The broader NHI security lesson is similar: if controls are not observable, they are hard to defend. NHI Mgmt Group highlights that 96% of organisations store secrets outside secrets managers in vulnerable locations, which is a different problem but the same accountability pattern: when evidence is weak, responsibility becomes harder to prove.

Related resources from NHI Mgmt Group

• Who is accountable when fraud starts on social media or SMS and ends in a payment?
• Who is accountable when a customer is tricked into authorising a fraudulent payment?
• Who is accountable when a workflow platform compromise leads to downstream cloud or SaaS abuse?
• Who should be accountable for third-party account connections in application workflows?