# BRD-146 — The DBA must be consistent with the legal name and every other field

> The DBA must be recognisably the same business as the legal name, the website, and the campaign — not an unrelated third name.

- **Rule ID:** BRD-146
- **Layer:** Brand (`BRAND`)
- **Checks:** `brand.dba vs brand.company_name`
- **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:** AI judgement over the submitted form
- **Fix type:** Fix the field — a better value in the form clears it
- **Required by:** AWS, Bandwidth, HighLevel
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/brand/brd-146/

## Why this rule exists

Reviewers use the DBA as the bridge between a legal name nobody recognises and a website that carries a brand. When the DBA is a third, unrelated name, that bridge collapses and the registration reads as three businesses stapled together — which is what an unauthorised reseller registration actually looks like. Multi-brand retailers reach this honestly by putting the group name in one field and a shopfront in another.

## How to fix it

Set the DBA to the name customers actually see from this brand — the one on the website header and in the message sender line. If the business genuinely trades under several names, register a separate brand per name rather than listing one and messaging under another. Done when the DBA, the website title and the name in the samples are the same business.

## Example of a compliant value

```text
company_name: Acme Coffee Co, LLC · dba: Acme Coffee · website: acmecoffee.com — one business, three consistent renderings
```

## Provider rejection codes

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

## Notes

Bandwidth grades this MEDIUM and AWS HIGH; the strictest is kept per the strict-superset model.