# BRD-234 — Vet before the campaign, not after the volume disappoints

> External vetting should be ordered before registering a campaign that needs material volume.

- **Rule ID:** BRD-234
- **Layer:** Brand (`BRAND`)
- **Checks:** `the vet record`
- **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:** Deterministic (settled in code from the submitted values)
- **Fix type:** Wait on an external system or a required interval
- **Required by:** Telnyx, T-Mobile
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/brand/brd-234/

## Why this rule exists

An unvetted brand starts at the bottom carrier tier — a couple of thousand messages a day — and the tier is what the campaign inherits at registration. Ordering the vet afterwards works, but the launch has already been scheduled against throughput the brand does not have, and the vet takes days. The cost of getting this wrong is a missed send date rather than a rejection, which is why nothing flags it.

## How to fix it

Decide the daily volume the programme needs, then order the vet if it is above the unvetted floor of roughly 2,000 messages a day. Do it before the campaign is registered, and allow several days for the result.

## Check this yourself

**Does the volume this programme needs exceed the unvetted daily floor of roughly 2,000 messages a day?**

1. Do the arithmetic: list size and send frequency against the unvetted cap.
2. If the first exceeds the second, order the vet before registering the campaign and allow several days for the result — the campaign inherits the brand's tier at registration.

*What wrong looks like:* Nothing is rejected. The launch is scheduled against throughput the brand does not have, and the vet that would fix it takes days that the send date does not allow.

## Notes

Whether a vet was ordered is a fact about the account rather than about the registration, so this reports UNCLEAR rather than guessing. What the user has to do is the arithmetic: list size against the unvetted daily cap, and if the first exceeds the second, the vet is a prerequisite rather than an upgrade.