Unregistered and P2P-classified traffic has a hard per-number ceiling

The requirementstatement

Traffic classified as P2P or unregistered is limited to roughly fifteen messages or segments per number per minute.

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: per-number per-minute send rate
Where it liveslayer: OperationalOPERATIONAL
How Ekas settles itdetectability: External recordEXTERNAL_DATA; The fact that settles it lives in a register we cannot query, such as the IRS file, a postal database, or another provider’s tenant. Reported as a warning with the evidence to check, not as a pass.
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: AT&T
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

The ceiling is low enough that any real campaign hits it immediately, which is the point: it is what makes registration the only viable path. Senders meet it while testing before their campaign is approved and conclude the platform is slow, then build a sending schedule around a limit that would have gone away.

How to fix itremediation

Do not size a programme against unregistered throughput. Wait for the campaign to be approved and provisioned before measuring what the number can do. Done when the rate you planned against is the registered one.

Check this yourselfattestation

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

Were the numbers you benchmarked throughput on attached to an approved campaign at the time?

1Check when the benchmark was taken against when the campaign was provisioned.
2Unregistered and P2P-classified traffic is capped at roughly fifteen messages or segments per number per minute — low enough that any real campaign hits it immediately.
3Re-measure after provisioning, and plan against that number.

What wrong looks like: A team tests before approval, concludes the platform is slow, and builds a sending schedule around a limit that would have gone away.

Notesnotes

A carrier-applied rate we cannot observe. What the user has to check is whether the numbers they benchmarked on were attached to an approved campaign at the time — benchmarks taken before provisioning are the usual source of a wrong plan.

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 keywordHighHIGH OPS-035The mandatory keywords must work over MMS tooHighHIGH OPS-044Suppression is brand-wide, not per numberHighHIGH OPS-047A state may give you less time than the federal limitHighHIGH OPS-052Silence after a scope question revokes everythingHighHIGH OPS-053A STOP answering a scope question must not be answered with anotherHighHIGH

All operational rules

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