Propagating Preference Changes Across Systems

The deadlines are outer limits

Rules set the latest acceptable time, not a good one. In Great Britain, self-excluded customers must be removed from marketing databases or flagged "within two days of receiving the completed self-exclusion notification" under code 3.5.3. In Ontario, since BetGuard launched on May 14, 2026, Standard 2.14.1 of the Alcohol and Gaming Commission of Ontario (AGCO) requires operators, "no later than 24 hours after an individual is added to the Centralized Self-Exclusion Registry," to "take all reasonable steps to prevent any marketing material, incentives or promotions from being sent to that individual." For opt-outs, the Australian Communications and Media Authority (ACMA) requires unsubscribe requests to be honored "within 5 working days", and other markets are listed in opt-out deadlines in each market.

A well-built stack should apply each of these in minutes. The gap between the legal limit and the technical possibility is the margin that protects customers when something goes wrong.

Push, confirm, retry

1. Write first. The change is written to the permission or safeguarding store before anything else.
2. Publish. The store publishes an event in the format set out in the customer event model.
3. Consume. Each connected tool applies the event and returns an acknowledgment.
4. Retry. Events without an acknowledgment are retried with backoff, and an alert fires after a set number of failures.
5. Reconcile. A daily job compares each tool's view with the source and corrects differences.

Queued and scheduled sends

A campaign scheduled yesterday for this evening was built on yesterday's facts. When an opt-out or exclusion event arrives, cancel any queued message for that customer that the change affects. If a tool cannot cancel individual messages, the send-time gate described in consent-gated workflows has to catch it.

When a tool was offline

If a tool misses events, it must not resume sending until it has caught up. Two safeguards:

• Each tool records the last event it processed and replays from that point on restart.
• Each send re-checks the decision point, so an out-of-date local copy cannot by itself cause a send.

Example, illustrative only. The text message tool is down from 02:00 to 04:00. At 03:10 a customer self-excludes. On restart, the tool replays events from 02:00, applies the exclusion and cancels the customer's 08:00 reminder. Had the replay failed, the 08:00 send would still call the decision point and be suppressed.

Evidence

Log when each tool received and applied each change. Code 5.1.11 asks licensees to "be able to provide evidence which establishes that consent", and the same logs show when a withdrawal took effect. Test propagation as part of the workflow test plan, and ask vendors to demonstrate queued send cancellation using the automation platform tests.

Designing the event consumer

Each tool that consumes changes should follow the same small set of rules:

• Apply exclusion and objection events before any other event in a batch.
• When an event cannot be applied, for example because the customer is unknown to the tool, store it and retry rather than dropping it.
• Report its last processed event so the reconciliation job can find tools that have fallen behind.

Monitoring

Show three numbers on an operations dashboard: events published, events acknowledged by each tool, and the age of the oldest unacknowledged event. An alert on the last number catches most propagation problems before they reach a customer.