# OPS-156 — Watch for traffic that is being pumped

> Content and traffic patterns consistent with artificially inflated traffic must be detected and rejected.

- **Rule ID:** OPS-156
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `traffic pattern and destination distribution`
- **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest.
- **When it bites:** Falls due after approval, once you are live and sending
- **How it is detected:** Not knowable before submission — reported with its deadline
- **Fix type:** Wait on an external system or a required interval
- **Required by:** Twilio, Telnyx
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-156/

## Why this rule exists

Artificially inflated traffic is fraud committed through your account rather than by you: an attacker drives OTP or verification sends to number ranges that pay them a share of the termination fee, and the bill is yours. The signature is a destination distribution that does not look like your customers — sudden concentration in unusual ranges or countries — and it costs real money for as long as nobody is watching.

## How to fix it

Rate-limit verification and OTP endpoints per source, alarm on shifts in destination distribution, and cap spend per hour so a pumping attack is bounded. Done when an unexpected concentration of destinations pages somebody within the hour.

## Common mistakes

- A CAPTCHA on the form does not stop this — the attack drives the API behind it, so the control has to sit at the send.

## Check this yourself

**Is there a spend cap and a destination-distribution alarm on every endpoint a stranger can trigger?**

1. List the endpoints that send without a logged-in user — verification and OTP are the usual ones.
2. Rate-limit per source, cap spend per hour, and alarm on shifts in destination distribution.
3. A CAPTCHA on the form does not stop this: the attack drives the API behind it, so the control has to sit at the send.

*What wrong looks like:* An attacker drives OTP sends to number ranges that pay them a share of the termination fee. It is fraud committed through your account rather than by you, the bill is yours, and the exposure is unbounded until a cap exists.

## Notes

A pattern in live traffic. What the user has to do is put a spend cap and a distribution alarm on any endpoint a stranger can trigger, because the exposure is unbounded until one exists.