Cooling-off periods and breaks

1) What is cooling-off and why is it needed

Cooling-off - a voluntary pause that the player turns on himself to temporarily exclude the possibility of betting/deposits and reduce impulsive behavior. Unlike self-exclusion, cooling-off is usually shorter, easier to activate and automatically expires.

• Reducing the risk of harm and complaints/chargebacks.
• Meet RG licensing expectations and best practices.
• Increase brand trust and long-term sustainability.

2) Break taxonomy

3) Application rules and boundaries

It is activated instantly. Game activities and deposits are blocked until the end of the period.

Cancellation before expiration is not allowed. (Otherwise, the meaning of "cooling" is lost.)

Account access is usually saved to view history and withdraw funds.
Bonuses/promo: with active cooling-off - no promo, user in the global suppression list.
Reactivation is allowed; limit the frequency if this does not impair protection.
Escalation: with frequent inclusions, → offer a longer period or self-exclusion.

4) UX patterns and finished texts

Principles: clear, short, no pressure to continue, equal visibility "Break "/" Continue "(if applicable), no promos.

• Header/profile → "Self-control": buttons "Break 15 min," "Cooling-off," "Self-exclusion."
• There are quick action buttons in Reality Check and on limit screens.

• Micro-break: "Pause for 15 minutes. During the pause, rates and deposits are not available"
• Cooling-off: "Select 24 h· 48 h· 72 h· 7 days· 14 days· 30 days. During the period, play and deposits are not available. You cannot cancel early"
• Confirmation: "Cooling-off activated before [date, time, TZ]. You can log in to withdraw funds and view the story. Ads are disabled"
• Escalation: "You often use short pauses. We recommend 30 days of cooling-off or self-exclusion for more stable control"

5) Thresholds and triggers

From Reality Check: "Break 15 min" button at 60/90 min of the game, "Cooling-off until tomorrow" when the loss limits are exceeded.
Behavior: a series of lead cancellations, a rapid rise in bets after losses (chasing) → a tip about cooling-off.
Night time: after 02:00 local TZ - strengthen pause offer.
Child/vulnerable modes: tighter presets on timing.

6) Integration and interaction with the RG circuit

Limits of deposits/losses/time: with active cooling-off - ignore their state, all the same block.
Self-exclusion: always more priority and longer; if enabled, cooling-off.
Marketing/CRM/Ads: immediate synchronization of suppression in all channels and affiliates.
KYC/AML: conclusions allowed if KYC is observed; anomalies during cooling-off → increased scoring.

7) Architecture and fail safes

• RG Engine/Breaks Service: storage of break statuses, deadlines, reasons; Read/write API.
• Auth/Game/Payments Gateways: synchronous predicates (no bets/deposits on active break).
• CRM/Ads Hub: real-time suppression and withdrawal at the end of the term.
• Event Bus: `break. started`, `break. ends_at`, `break. ended`, `suppression. applied`.
• Audit/WORM: unchangeable activation/expiration/communication logs.

Fail-safe: if Breaks Service is unavailable - "strict mode" (prohibit bets/deposits) or use the last k-time snapshot; all deviations are logged.

8) Cooling-off policy (skeleton for wiki)

1. Scope: all brands/channels/locations.
2. Dates: list of available (24 h-180 days), local TZ in the interface.
3. Rules: early cancellation is not possible; input is allowed for history/output; promo is prohibited.
4. Data: minimization, signal retention (e.g. 12-24 months), DPIA for profiling.
5. Escalations: frequent inclusion → recommendation of self-exclusion; rules for the vulnerable.
6. Communications: templates of letters/fluffs, links to help resources.
7. Reporting: metrics, SLA, auditing.

9) Metrics and SLO

Break Adoption Rate: Proportion of players who took advantage of breaks.

Time-to-Enforce - Click to actually deny rates/deposits (<1-2s)

Suppression Accuracy: no promo during break (~ 100%).
Harm-Signal Reduction: 30-day decline in chasing/night long sessions.
Repeat Breaks → Escalation: share escalated to long cooling-off/self-exclusion.
Complaint/Chargeback Rate: downward trend after implementation.
System Availability (Breaks): ≥99. 9%.

10) RACI (roles and responsibilities)

11) Checklists (operating)

Before launch

• Dates and texts (locals, TZ) are defined.
• Predicates configured in Auth/Game/Payments.
• Suppression is connected in all channels (email/SMS/push/ads/affiliates).
• WORM auditing and SLO alerts enabled.
• DPIA conducted, updated RG policy.

In operation

• Time-to-Enforce and Suppression Accuracy monitoring.
• Weekly trigger calibration (night/chasing).
• Resolving complaints/incidents, improving texts and UX.

Incidents

• Fallback "strict mode" in case of service failures.
• Communication to players and status adjustments by logs.

12) Scenarios and examples

A. A quick break from Reality Check

Player 60 min in session, window pops up: "15 min break?" → click → bet/deposit block, timer, then auto-shoot.

B. Cooling-off for 7 days

The player turns on self-control in the center. Immediately: game/deposit block, suppression turns on. Input to output is allowed. After 7 days, the status is automatically removed.

C. Repeated short pauses

3 times a week, the player includes a 24-hour cooling-off → an automatic recommendation of "30 days" or self-exclusion, an alt-screen with help resources.

13) Justice and privacy

Explainability: briefly explain what and why is blocked, when it is completed, how to withdraw funds.
Minimization: keep only the facts of inclusion/expiration, reason (reason code) and term.
Availability: contrasting elements, simple formulations, support for screen readers.

Without "dark patterns."

14) Implementation Roadmap (6 steps)

1. Policy and DPIA: define terms and rules, text templates, suppression procedures.
2. Architecture: implement Breaks Service, guards in Auth/Game/Payments, Event Bus, WORM audit.
3. UX/content: add buttons to profile/Reality Check, localization, availability.
4. Integrations: CRM/Ads/affiliates (suppression), CCM/conclusions.
5. Observability: dashboards of metrics and SLO, alerts, post-morems of incidents.
6. Improvement: A/B wording/location, trigger calibration, re-case analysis.

Result

Cooling-off and breaks are not a "cosmetic" function, but an end-to-end protective circuit: fair terms and rules, instant technical application, suppression promo, transparent UX, communication with limits and self-exclusion, strict observability and file safes. This approach reduces harm, strengthens compliance and increases confidence in your product.