Accountability should sit with the business owners of the payment journey, supported by fraud, security, compliance, and operations teams. APP scams usually succeed when verification, approval, and customer warning steps are too weak or inconsistent. Clear ownership, documented controls, and tested escalation paths are essential so the response does not become fragmented after losses occur.
Why This Matters for Security Teams
Accountability for authorised push payment scams is not just a fraud question. It sits at the intersection of customer authentication, payment approval, warnings, escalation handling, and post-event recovery. When ownership is vague, gaps appear between fraud, security, compliance, and operations, and those gaps are exactly where scams succeed. The control problem is broader than a single failed payment check and is better understood as a governance failure across the payment journey, consistent with NIST SP 800-53 Rev 5 Security and Privacy Controls and the governance depth in Ultimate Guide to NHIs.
Practitioners often overfocus on the customer who authorised the transfer and underfocus on the business processes that shaped that authorisation. If warnings are inconsistent, approvals are poorly segmented, or escalation paths are unclear, the organisation has effectively created a scam-friendly workflow. In practice, many security teams encounter accountability disputes only after funds have already moved and the investigation begins.
How It Works in Practice
The most effective accountability model assigns a named business owner for the payment journey, then makes fraud, security, compliance, customer operations, and technology teams accountable for the controls they operate. That means the owner of the journey is responsible for the outcome, while each supporting function is responsible for its part of the control chain. This mirrors good control design in NIST guidance: policy ownership, control testing, exception handling, and evidence retention should be explicit rather than implied.
In operational terms, the organisation should define who approves payment rules, who tunes scam detection, who decides when extra verification is required, and who can pause or reverse a payment. Clear runbooks matter because APP scams often exploit ordinary workflows rather than technical compromise. For example, a scam may succeed because a warning banner was not shown, a callback was bypassed, or a high-risk transfer was treated as routine. The control model should therefore include:
- Named ownership for each payment channel and product line
- Documented approval thresholds for high-risk transfers
- Escalation paths for suspected coercion or impersonation
- Testing of warnings, callbacks, and step-up verification
- Evidence capture for disputes, complaints, and reimbursement decisions
The governance lesson from Ultimate Guide to NHIs also applies here: if an important control is not owned, reviewed, and rotated through accountable teams, it will drift into weak practice over time. These controls tend to break down when payment journeys span multiple systems and no single team can enforce end-to-end decision rights.
Common Variations and Edge Cases
Tighter control ownership often increases operational overhead, requiring organisations to balance scam resistance against customer friction and settlement speed. There is no universal standard for reimbursement allocation across all markets, so the accountability model must match local regulation, payment rails, and customer expectations. Current guidance suggests the business owner should still remain accountable even when some decisions are delegated to operations or outsourced service providers.
Edge cases arise when scams involve multiple channels, such as a call centre, mobile banking, and instant payments all in one journey. In those cases, shared responsibility should not mean shared ambiguity. The organisation should predefine which team owns the decision, which team supplies the evidence, and which team handles remediation. That becomes especially important where third parties influence warnings, authentication, or payment execution, because external dependencies can blur ownership unless contracts and controls are explicit.
For control design and audit evidence, the baseline should align with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where accountability, monitoring, and response obligations must be demonstrable. When the organisation cannot clearly name who owned the journey before the scam, it usually means the control framework was never strong enough to stop it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Accountability depends on clear governance roles for the payment journey. |
| NIST SP 800-63 | Strong identity proofing supports high-risk payment authorisation decisions. |
Assign a named owner for scam risk decisions and review accountability at least quarterly.
Related resources from NHI Mgmt Group
- Who is accountable when deepfake scams spread on dating apps?
- Who is accountable when an authorised fraud payment is not blocked?
- Who is accountable when payment scams occur on customer-friendly rails like P2P?
- Who is accountable when AI spend grows faster than revenue and there is no finance-grade metering?
