# BRD-235 — The daily carrier cap is an EIN-level allowance, pooled across CSPs

> The T-Mobile daily brand cap is an allowance against the tax ID, pooled across every campaign and every CSP that registered it, resetting at midnight Pacific.

- **Rule ID:** BRD-235
- **Layer:** Brand (`BRAND`)
- **Checks:** `daily volume against brand.ein`
- **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** External record we cannot query — reported as a warning to verify
- **Fix type:** Wait on an external system or a required interval
- **Required by:** T-Mobile, TCR
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/brand/brd-235/

## Why this rule exists

Because the cap attaches to the EIN rather than to the brand, splitting traffic across two providers does not double it — the two routes draw from one bucket, and the second one starts failing when the first has used the allowance. Teams add a provider specifically to increase capacity and get no more messages delivered, with the failures landing on whichever route sent last.

## How to fix it

Plan volume against one allowance per tax ID, not per provider or per campaign, and reconcile sends across every route before scheduling a large day. The window resets at midnight Pacific, which is the boundary to schedule around.

## Check this yourself

**Have you added up the daily traffic across every CSP and every campaign that shares this tax ID?**

1. List every provider holding a brand on this EIN — including accounts another team set up. The cap does not care that they are separate accounts.
2. Reconcile the total against one allowance before scheduling a large day, and schedule around the midnight Pacific reset.

*What wrong looks like:* A second provider is added specifically to increase capacity, and no more messages are delivered. Both routes draw on one bucket, and the failures land on whichever sent last.

## Notes

Absorbs OPS-118, which states the same pooling behaviour. Volume is not visible at registration time. What the user has to do is add up the traffic across every CSP that holds a brand on this EIN — including ones another team set up — because the cap does not care that they are separate accounts.