# BRD-076 — Changing the mobile number re-runs the verification

> Any change to the sole-proprietor mobile number reverts the brand to UNVERIFIED and requires the OTP to be run again.

- **Rule ID:** BRD-076
- **Layer:** Brand (`BRAND`)
- **Checks:** `brand.mobile_phone`
- **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright.
- **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:** TCR
- **Applies:** Applies when the brand is a sole proprietor.
- **Canonical URL:** https://ekas.io/rules/10dlc/brand/brd-076/

## Why this rule exists

The number is the identity, so replacing it is a new identity claim rather than a contact-details update — the status drops and campaigns under the brand stop being registrable until a fresh YES arrives. People change it for entirely ordinary reasons, usually because they switched phones or mistyped a digit, and nothing warns them that a verified brand is about to go back in the queue.

## How to fix it

Make the change with the new handset in hand, and expect a fresh verification text immediately. Do not change the number while a campaign is being reviewed — the brand will drop to UNVERIFIED underneath it.

## Check this yourself

**Is the new handset in the owner's hand right now, and is there no campaign under review?**

1. Treat this as a re-verification rather than a contact-details edit: the brand drops to UNVERIFIED the moment the number changes.
2. Make the change with the owner present, expect the verification text immediately, and check no campaign is mid-review — it will be judged against an unverified brand.

*What wrong looks like:* A digit is corrected on a verified brand mid-week. The status drops, campaign registration stops, and nothing warned that a working brand was going back into the queue.

## Notes

We can see that the number is being changed; we cannot see whether the new OTP was answered, which is BRD-075. What the user has to do is treat this as a re-verification rather than an edit, and schedule it accordingly.