# POL-110 — A cart-reminder programme must be reflected in the terms

> Where the programme sends shopping-cart reminders, the SMS terms must describe them.

- **Rule ID:** POL-110
- **Layer:** Policy pages (`POLICY_PAGE`)
- **Checks:** `SMS terms body`
- **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:** Fix the privacy policy or SMS terms
- **Required by:** T-Mobile, CTIA, TCR
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-110/

## Why this rule exists

T-Mobile requires the terms to reflect the cart programme, and the reason is the same one behind the privacy-policy rule: a message triggered by watching what somebody did is not what "promotional offers" prepared them for. A retailer switching the flow on inside a platform changes what the programme sends without touching any document.

## How to fix it

Add cart reminders to the message types the terms describe, and say how the number is linked to the basket. Done when the terms name them alongside whatever else the programme sends.

## Example of a compliant value

```text
Acme Coffee Rewards sends promotional offers, rewards updates, and reminders when you leave something in your basket.
```

## Common mistakes

- The privacy policy owes the detection mechanism (POL-109) and the opt-in disclosure owes the message type (WEB-068). Fixing the terms alone leaves two of the three.

## Notes

Conditional on cart-reminder traffic being in scope, which no applicability dimension expresses. The check reads the campaign copy for the signal and passes where it finds none.