# BRD-154 — The account tier cannot be changed more than once a quarter

> brandRelationship must not be changed more than once in any three-month period.

- **Rule ID:** BRD-154
- **Layer:** Brand (`BRAND`)
- **Checks:** `brand.brand_relationship`
- **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review.
- **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 to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/brand/brd-154/

## Why this rule exists

The tier feeds commercial reporting rather than compliance, so the registry rate-limits it instead of validating it — and the rejection arrives as a bare error code on an edit that seemed trivial. It bites during account reviews, when someone tidies up several brands at once and one of them was already touched last month.

## How to fix it

Leave the tier as it is until three months have passed since the last change. Nothing about the brand's standing depends on it, so there is no cost to waiting — and no route to an exception if you do not.

## Provider rejection codes

| Provider | Code | Resubmission allowed |
| --- | --- | --- |
| TCR | `528` | yes |

## Check this yourself

**Do you know when this brand's account tier was last changed, and was it more than three months ago?**

1. Check the brand's edit history for a previous change to the tier.
2. Where the date is unknown, assume it was recent — this field is usually only touched during exactly the kind of account review that would touch it twice.

*What wrong looks like:* Someone tidies up several brands at once and one was already edited last month. The rejection is a bare error code on an edit that seemed trivial, and there is no exception route.

## Notes

The cooldown is enforced at the registry against a change history we only see when the caller supplies it. The user has to know when the tier was last edited; where that is unknown, the safe assumption is that it was recent, because this field is usually only touched during exactly the kind of review that would touch it twice.