# BRD-174 — Per-EIN brand counts are capped even where several are allowed

> Where a provider permits more than one brand per tax ID, the number is still capped and each additional brand needs a documented business reason.

- **Rule ID:** BRD-174
- **Layer:** Brand (`BRAND`)
- **Checks:** `brand.ein across the registry`
- **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; Human check — only someone holding the document can settle it
- **Fix type:** Wait on an external system or a required interval
- **Required by:** Twilio
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/brand/brd-174/

## Why this rule exists

The looser model is not an open door: the cap exists because a single business fragmented across many brands defeats the reputation model the framework runs on. Agencies reach the cap by creating a brand per client campaign rather than per client, and the refusal arrives on the one that mattered.

## How to fix it

Keep one brand per legal entity and use campaigns for everything below that. Where several brands on one tax ID are genuinely required, write the business reason down before submitting — you will be asked for it, and after a refusal it is too late.

## Provider rejection codes

| Provider | Code | Resubmission allowed |
| --- | --- | --- |
| Twilio | `30898` | yes |

## Check this yourself

**Do you keep your own tally of brands registered against each tax ID, across every provider you use?**

1. Count them. The registry-wide number is invisible to you and to us.
2. Keep one brand per legal entity and use campaigns for everything below that.
3. Where several are genuinely required, write the business reason down before submitting — you will be asked, and after a refusal it is too late.

*What wrong looks like:* An agency creates a brand per client campaign rather than per client, hits the cap, and the refusal lands on the one that mattered. A second attempt on the same EIN after a reuse rejection is read as evasion rather than as a retry.

## Notes

Absorbs OPS-366, which states the same minimisation duty and adds the warning against resubmitting after an EIN-reuse rejection — a second attempt on the same EIN is read as evasion rather than as a retry. The count is registry-wide and invisible to us; what the user has to do is keep their own tally of brands registered against each EIN, across every provider they use.