Who is accountable when SMS pumping drives fraud losses in a marketplace?

Why This Matters for Security Teams

sms pumping is not just a cost anomaly. It is a control failure that converts verification traffic into monetisable abuse, often by exploiting signup, password reset, or one-time passcode flows. When fraud teams see the chargeback or campaign abuse but identity and platform teams own the triggering workflow, accountability becomes blurred. That is exactly where attackers operate: in the seams between policy, routing, and business logic.

For NHI Management Group, the key lesson is that verification channels must be governed like high-risk access paths, not convenience features. The same identity and secret discipline that protects service accounts also applies to systems that decide when an SMS is sent. Weak controls around automation, retries, partner integrations, and rate limits can turn an ordinary marketplace feature into an abuse amplifier. NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for explicit access enforcement, monitoring, and auditability at control points that process sensitive transactions.

The practical signal is simple: if no one can explain who owns the decision to send, challenge, or suppress a verification message, the organisation does not truly own the risk. In practice, many security teams encounter SMS pumping only after fraud losses have already accumulated across multiple product releases.

How It Works in Practice

Accountability should follow the verification workflow end to end. That means a named control owner for the rules that decide whether an SMS is triggered, the thresholds that suppress suspicious activity, and the telemetry that proves those rules are working. In mature environments, IAM defines the identity proofing and session context, fraud owns abuse patterns and economic signals, and platform engineering owns implementation, logging, and fallback behaviour. The business owner remains accountable for the customer journey, but the control owner must have authority over the workflow itself.

Practically, this includes:

• Challenge logic that evaluates device, number reputation, velocity, and prior abuse before sending.
• Per-route and per-partner limits so one compromised integration cannot create unlimited SMS volume.
• Immutable logs for every decision to send, delay, block, or step up verification.
• Fraud and SRE alerts tied to spend, error rates, and unusual destination patterns.
• Periodic review of outsourced messaging providers and API credentials with the same rigor used for other NHIs.

This is where NHI governance becomes directly relevant. The systems that trigger SMS often rely on API keys, service accounts, and automation tokens, and the NHI lifecycle controls in the Ultimate Guide to NHIs — The NHI Market show why visibility, rotation, and offboarding matter when a business process can be abused at scale. CISA’s guidance on abused verification channels also aligns with this approach, as does identity control design in NIST frameworks. Where possible, teams should map SMS-trigger decisions to explicit policy gates rather than leaving them embedded in application code or vendor defaults.

Current guidance suggests that the most effective operating model is a joint ownership structure with one accountable control owner and clear technical delegations. These controls tend to break down in highly distributed marketplaces because local product teams can change verification flows faster than central fraud teams can monitor the resulting abuse.

Common Variations and Edge Cases

Tighter verification controls often increase friction and support cost, so organisations must balance fraud suppression against conversion loss and customer abandonment. There is no universal standard for this yet, but best practice is evolving toward risk-based verification rather than fixed SMS dependency.

Two edge cases matter. First, some marketplaces use third-party authentication, messaging aggregators, or regional telecom partners, which means the organisation may not control every hop in the decision chain. In those environments, accountability still sits with the marketplace, but evidence collection must extend to vendor SLAs, routing rules, and escalation paths. Second, SMS pumping may coexist with account takeover or synthetic identity fraud, making it easy to misclassify spend as mere abuse rather than a broader control breach.

For that reason, current guidance suggests pairing fraud analytics with identity assurance and workflow governance. The JetBrains Marketplace AI Plugin Campaign is a useful reminder that exposed secrets and abused automation can drive large-scale abuse when controls are not tightly scoped. NIST control baselines are helpful here, but no standard removes the need for a clear owner who can stop the SMS before it becomes a fraud loss.

Related resources from NHI Mgmt Group

• Who is accountable when SMS fraud drives regulatory penalties or service disruption?
• Who is accountable when fraud starts on social media or SMS and ends in a payment?
• Who is accountable when SMS toll fraud is enabled by authentication design?
• Who should own marketplace fraud accountability when losses appear late?