Who is accountable when fraud depends on both identity abuse and payment misuse?

Why This Matters for Security Teams

When fraud depends on both identity abuse and payment misuse, the real risk is not just a bad transaction. It is the handoff failure between controls that were each designed for a different team, process, or data set. Identity teams may spot anomalous login behaviour, while fraud teams see a suspicious payment pattern, but neither signal is sufficient alone. That is why accountability has to be defined across the full chain of authentication, recovery, authorisation, and transaction review.

For security leaders, this is a governance problem as much as a detection problem. NIST guidance on control ownership in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need to assign controls, monitor effectiveness, and evidence response. In practice, that means identity assurance cannot be treated as “upstream” and payment fraud cannot be treated as “downstream” with a clean boundary between them. The attack succeeds when ownership is fragmented and escalation paths are unclear.

In practice, many security teams encounter this only after a customer dispute or loss event exposes that no single group owned the full abuse path.

How It Works in Practice

The cleanest operating model is shared accountability with explicit control boundaries. IAM typically owns authentication strength, account recovery, session risk, and identity proofing. Fraud and payments teams own transaction monitoring, beneficiary checks, velocity rules, and step-up decisions. Customer operations owns remediation, customer communication, and case closure. Security or GRC usually coordinates policy, evidence, and control testing so the model does not depend on informal escalation.

A practical way to structure this is to define the abuse path from identity compromise to payment execution, then map each stage to a named control owner. That avoids the common trap where fraud teams assume identity signals were already blocked and identity teams assume transaction monitoring will catch the abuse later. Good accountability also requires shared telemetry, because separate dashboards create separate stories. When identity events and payment events are not joined, teams miss the sequence that matters.

• Define which team can challenge, step up, freeze, or approve at each stage of the customer journey.
• Use one case record or investigation thread so identity recovery, payment review, and customer contact stay linked.
• Set clear thresholds for when fraud findings trigger identity resets, credential revocation, or account re-verification.
• Test the full path with scenario-based exercises, not just isolated control checks.

This is where a control framework helps. MITRE ATT&CK is useful for describing the attacker behaviour that links credential abuse to downstream misuse, while CISA Zero Trust Maturity Model supports the idea that trust should be continuously evaluated rather than granted once at login. For identity assurance, the strongest organisations also use NIST SP 800-63 Digital Identity Guidelines to separate proofing, authentication, and recovery responsibilities. These controls tend to break down when fraud operations sit outside the incident workflow and cannot trigger identity containment fast enough.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance faster fraud response against clearer ownership and auditability. That tradeoff becomes most visible when the same event may be either a genuine customer error, an account takeover, or an authorised but risky transaction. There is no universal standard for this yet, so current guidance suggests defining decision rights by scenario rather than forcing one team to own every outcome.

In higher-risk environments, such as payments with chargeback exposure or regulated financial services, the payment team may need the authority to block or delay transactions while IAM handles recovery. In consumer-facing environments, customer operations may need to lead comms and case handling even when security sees the original compromise. The key is not which team “wins” the incident, but whether the organisation can prove who acted, when, and on what evidence.

Identity abuse can also be indirect. A fraud case may start with a reset attack, a SIM swap, or social engineering of support staff, then end in payment diversion. That is why the best practice is evolving toward joint playbooks, shared metrics, and common loss taxonomy. Where agentic automation is used, organisations should also treat AI-driven decisioning as a governed control surface, not a black box. The model’s recommendation can assist the workflow, but accountability for the action still sits with the named owner.

As a practical rule, shared accountability works best when one team is responsible for the decision, another for the evidence, and a third for the customer outcome.

Related resources from NHI Mgmt Group

• Who is accountable when resident identity fraud causes service abuse?
• Who is accountable when fraud starts on social media or SMS and ends in a payment?
• Who is accountable when an authorised fraud payment is not blocked?
• Who is accountable when weak authentication leads to payment fraud?