# POL-112 — Location-triggered messaging must be described in the policy

> The privacy policy must describe how location data is collected and why, where messaging is triggered by location.

- **Rule ID:** POL-112
- **Layer:** Policy pages (`POLICY_PAGE`)
- **Checks:** `privacy policy 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:** AI judgement over the submitted form
- **Fix type:** Fix the privacy policy or SMS terms
- **Required by:** Klaviyo
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/policy-page/pol-112/

## Why this rule exists

A message that arrives because someone walked past a shop is the kind of thing consumers find startling, and the policy is the only place they can find out it was going to happen. Location tracking is usually switched on inside a marketing platform rather than built deliberately, so the practice exists long before anyone thinks to document it.

## How to fix it

Describe the collection method, the messaging use and the opt-out in the messaging section. Done when someone who receives a location-triggered message can find out why in the policy.

## Example of a compliant value

```text
If you enable location in the Acme Coffee app we use it to text you when you are near a store with an offer on. Turn location off in the app to stop those texts without leaving the programme.
```

## Notes

Conditional on the programme being location-triggered, which no applicability dimension expresses; the criteria pass immediately where nothing in the registration indicates location triggering.