Watch for traffic that is being pumped

JSONMarkdown

The requirementstatement

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

Severityseverity
HighHIGHRejected by at least one carrier or provider, and a common cause of failure at the rest.
When it bitesphase
After you are livepostFalls due once you are sending: STOP handling, quiet hours, suppression, record retention.
What is checkedobject
traffic pattern and destination distribution
Where it liveslayer
OperationalOPERATIONAL
How Ekas settles itdetectability
Post-submissionUNDETECTABLE_PRE_SUBMISSION
The subject does not exist yet at submission time: a reply window, an expiring PIN, a queue position. Reported with its deadline.
What the fix involvesfailureClass
Wait on someone elseTERMINAL_EXTERNAL
Needs an external system or a waiting period, such as IRS propagation, a vetting result, or a carrier queue.
Who requires itauthorities
TwilioTelnyx
When it appliesapplicabilityText
Applies to every 10DLC registration.

Why this rule existsrationale

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 itremediation

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 mistakespitfalls

  • 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 yourselfattestation

No tool can settle this one for you. Here is the check, and what wrong looks like.

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

  1. 1List the endpoints that send without a logged-in user — verification and OTP are the usual ones.
  2. 2Rate-limit per source, cap spend per hour, and alarm on shifts in destination distribution.
  3. 3A 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.

Notesnotes

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.

Rules you will hit next

Other operational rules at the same severity. A registration is judged as a whole, not rule by rule.

OPS-034A programme in another language still owes the English keywordHighHIGHOPS-035The mandatory keywords must work over MMS tooHighHIGHOPS-044Suppression is brand-wide, not per numberHighHIGHOPS-047A state may give you less time than the federal limitHighHIGHOPS-052Silence after a scope question revokes everythingHighHIGHOPS-053A STOP answering a scope question must not be answered with anotherHighHIGH

All operational rules

OPS-156 is one of 139 operational rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.

Reading the rules is the easy part.

Ekas runs every rule that gates approval, 823 of these 915, against your registration before it reaches the carrier. It reads your site, your policy pages and your opt-in the way a reviewer would, and hands you the fix, not just the verdict.

Talk to UsHow 10DLC works