Who is accountable when fraud starts on social media or SMS and ends in a payment?

Why This Matters for Security Teams

Fraud that starts on social media or by SMS and ends in a payment is rarely a single-event failure. It is usually a chain: a deceptive origin signal, a compromised or misused account, weak identity proof, and a payment or release control that trusted the wrong context. That makes accountability operational, not just legal. Security teams need evidence of what was known at each step, which identity signals were accepted, and which control could have interrupted the chain sooner.

Current guidance in NIST SP 800-63 Digital Identity Guidelines treats identity assurance as a graded decision, which matters here because not every inbound message, callback, or payment request deserves the same trust level. The same logic shows up in NHIMG research: the Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, underscoring how often the real weakness is in the identity chain that moves data or triggers action.

In practice, many security teams encounter liability questions only after funds are already gone, rather than through intentional trust design.

How It Works in Practice

The practical question is not just who clicked or who approved. It is whether the organisation had enough identity assurance at the point where a social message became a financial action. A fraudster may begin with a convincing SMS, a social profile takeover, or a lookalike domain, then pivot through a helpdesk workflow, callback process, payment instruction, or API-triggered payout. Accountability often follows the trust decision that enabled the transfer, even if the deception started elsewhere.

Security and fraud teams should trace the full sequence:

• What origin signal was first trusted, such as a phone number, social handle, email, or device.
• What identity proof existed at each handoff, including MFA strength, callback validation, and out-of-band verification.
• Whether the payment path required step-up verification, dual approval, or transaction limits.
• Which logs prove the decision maker, the channel, the account state, and the time of action.

That evidence trail matters because it shows whether the organisation used proportionate controls or accepted a low-assurance channel for a high-impact action. The NIST guidance on assurance levels is useful here, and NHIMG’s New York Times breach coverage is a reminder that identity compromise often travels through trusted workflows rather than through obvious perimeter intrusion. Stronger programs increasingly combine policy, context, and transaction risk scoring so a message alone cannot authorise a payment.

These controls tend to break down when the fraud path spans multiple teams and systems because no single owner can reconstruct the full trust chain fast enough.

Common Variations and Edge Cases

Tighter verification often increases friction for customers, employees, and frontline teams, so organisations have to balance fraud resistance against conversion, speed, and support burden.

There is no universal standard for assigning blame across social platforms, telecom channels, banks, and merchants. In some regimes, the payment provider may bear most of the responsibility if it failed to validate an unusual transfer. In others, the originating organisation may still face exposure if its staff, workflow, or identity controls were too weak. Best practice is evolving toward shared accountability with clear control ownership at each hop.

Edge cases are common when the payment is authorised by a human but initiated by a scammer, when a trusted business account is hijacked, or when an agentic workflow automatically converts a message into an outbound payment. In those cases, the right question is not only “who approved?” but “which control should have stopped a low-confidence origin from becoming a financial instruction?”

If the process depends on phone-based callbacks, shared inboxes, or manual exception handling, the chain often fails before the organisation can prove which party should carry the loss.

Related resources from NHI Mgmt Group

• Who is accountable when a workflow platform compromise leads to downstream cloud or SaaS abuse?
• Who is accountable when a SoD conflict leads to fraud or compliance failure?
• Who is accountable when root detection blocks legitimate customers or misses fraud?
• Who is accountable for third-party access after a campaign or project ends?