Self-exclusion and account blocking

1) Purpose and area

Ensure safe, transparent and legally correct self-exclusion and blocking mechanics to protect players, reduce harm and comply with licensing requirements. Coverage: web/mobile, game providers, payments/PSP, CRM/marketing, support (CS), Risk/AML, Legal/DPO, reporting to regulators.

2) Principles

Player safety priority. Any request for SE is processed immediately.
No pressure. Attempts to convince/reactivate during SE are prohibited.
Irreversibility in the period. Withdrawal or mitigation - only after a period of cooling and confirmation.
Completeness of blocking. Game/deposits/marketing/bonuses/PSP - under suppression.
Evidence. Decision logs, artifacts, receipts of shipments to registries.
Privacy. PII is minimized, RBAC access, retention storage.

3) Roles and RACI

RG Lead (process owner) - policy/metrics, escalation. (A)

CS/CRM - acceptance of applications, correct communications, launch suppression. (R)

Risk/AML - forced blocking at risks/markers of harm/sanctions. (R)

Product/UX/Engineering - UX streams, API SE/locks, integration with registries/providers/PSP. (R)

Legal/DPO - requirements localization, privacy/retention. (C)

Payments/Finance - hold/cancellation of deposits/conclusions by policy. (R)

Internal Audit - independent audits and CAPAs. (C)

Exec Sponsor (COO/CEO) — «tone from the top». (I/A)

4) Types of restrictions

4. 1 Voluntary

Time out (cool-off): 24 h/7/30 days.
Self-exclusion (SE): 6-12 months, or indefinite; reactivation is possible only by procedure (cooling + confirmation).

4. 2 Forced

RG blocking: with confirmed harm markers/inappropriate behavior.
Legal blocking: at the request of the regulator/court/registry.
AML/sanctions block: according to AML/sanctions policy (without tipping-off).

General: with any active restriction - full suppression of games/deposits/marketing/bonuses.

5) UX threads and copyright

5. 1 Initiation

From the profile and header: "Take a break "/" Self-exclusion." ≤ 3 clicks.
Clear deadlines and consequences (game/deposits/bonuses/communications).

5. 2 Confirmation

Clear screen with type/date/end date/what will be disabled.

Checkbox "I understand the consequences" and CTA: "Confirm self-exclusion."

5. 3 After activation

Interface unit, screen "self-exclusion is active until [date]."

Link to help and support resources.

5. 4 Mitigation/return

Only available after expiration + cooling period (e.g. 24-168 hours), with solution confirmation.

• "We will suspend access to games until [date] so you can pause."
• "Marketing messages are disabled. You can turn them on after the period ends"

6) Integrations and blocking loops

Self-exclusion registers (nat ./reg.) : registration/check-in and pre-deposit; realtime or T + 1 synchronization.
Game providers: 'session _ stop' event, banning new sessions; SE status is broadcast to the aggregator.
PSP/payments: block of new deposits/risk deviation; SE flags in anti-fraud.
CRM/marketing: suppression lists for e-mail/SMS/push/retention campaigns.
Affiliates - SE status notification to prohibit targeting/reactivation.

7) Data, logs and retention

• `user_id, restriction_type{cooloff|SE|RG|AML|legal}, start_at, end_at, source{self|rg|aml|reg}, reason_code, evidence_id, set_by, effective_at, cooldown_until, suppression_flags{games|deposits|crm|psp}, registry_case_id`.

• Audit of actions: who/when/what established, attempts to play/deposit during SE.
• Confirmations: registration receipts in registers, case IDs.

Retention: at least the period required by regulators (often 5-7 years); access strictly by RBAC/ABAC.

8) Harm markers and enforcement actions

Finance: rapid growth in losses/deposits, cancellation of conclusions, credit methods.

Behavior: night marathons, increased betting speed, repeated "almost limit."

Communications: requests to remove limits, signs of financial difficulties.

Social cues: "playing to close debts."

Escalation: from soft contacts → time limits → RG blocking → (if necessary) notification of the regulator/registry.

9) Payments and conclusions

New deposits are prohibited under any active restriction.
Conclusions: processed by policy (fair balance return, AML/RG check, no tipping-off).
Chargeback/disputes - according to the contract and laws; documentation is required.

10) Communications (without pressure and tipping-off)

SE confirmation: "Your self-exclusion is active until [date]. We've disabled access to games and newsletters so you can pause"

SE login attempt: "Account limited to [date]. Here are the support resources and timing information"

Request for early return: "Relaxation of restrictions is possible only after a cooling-off period."

AML locks: use neutral wording "standard security checks," without indicating suspicion.

11) Reporting and Compliance

Calendar of deadlines for sending events/registers; bill verification.
Report formats (CSV/XML/JSON/XLSX) and schema control (validators).
Data reconciliation: purse/GL ↔ RG reports/SE register; discrepancies> X% - incident.
Storage of confirmations on the acceptance of reports by the regulator.

12) Dashboard and KPI/KRI

SE Coverage: proportion of active SEs/timeouts.
Time-to-Block: The median from the player's request to the actual block (the goal is instant).
Suppression Integrity:% of SE players with all marketing/deposit channels disabled.
Attempts During SE - number of attempts to enter/deposit - control UX and informing.
Return After Cooldown: the proportion of returns after the end of the SE and their behavior.
Registry Sync SLA: timeliness of synchronizations/confirmations.
Complaints/Disputes: SE cases, percentage of resolved ≤ X days.
Audit Findings/Repeat: Recurring shortcomings.

13) Checklists

Before launch

• UX streams "timeout/SE/reactivation" ≤ 3 clicks; texts agreed.
• Integrations: SE registries, game providers, PSP, CRM-suppression.
• Logs are unchangeable, validators of reporting schemes in CI.
• CS and FAQ scripts published; the team is trained.
• Retention/Privacy Policy (DPO) approved.

Operations

• Any SE request - instant application and receipt.
• Mitigation - only after cooling and confirmation.
• Complaints/appeals - registered and answered on time.
• Marketing/PSP Suppression Checks - Scheduled.

Audit and control

• Quarterly samples of SE cases/locks and their artifacts.
• Reconciliation with GL/Wallet/CRM; discrepancies - CAPA.
• Retro on RG incidents with policy update.

14) Templates (quick inserts)

A) Timeout confirmation

B) Self-exclusion confirmation

C) Response to Early Withdrawal Request

D) Inform Affiliate

E) Message when trying to deposit during SE

15) Legal and privacy

Processing basis: legal interests/legal obligations for RG/SE; document flow for reporting.
DSAR: information is provided without prejudice to investigations/protection of third parties; SE data - taking into account local norms.
Cross-border: contractual guarantees and minimization.
Accessibility and localization: interfaces and letters in the market language, available formats.

16) Technical implementation (skeleton)

API RG/SE: `POST /cooloff`, `POST /self-exclusion`, `GET /restrictions`, `POST /reactivation-request`.
События: `se_activated`, `se_registry_synced`, `deposit_blocked`, `marketing_suppressed`, `reactivation_cooldown_passed`.
Policy Engine: cooling rules, suppression, PSP/game block.
DQ/Validations: status integrity in multi-provider environment; consistency of reports.
Monitoring: alerts in case of misalignment (registry/aggregator/PSP/CRM).

17) Frequent mistakes and how to avoid them

Complex flows SE. → shorten steps, move to header/profile.
Remove restrictions without cooling. → enforce in Policy Engine.
Marketing "leaks." → a single suppression flag and nightly checks.
No artifacts. → required receipts and links to registry ID.
Different statuses of providers/PSP. → periodic reconciliations and auto-remediation.

18) Interconnections

Responsible play and limits are politics and harm markers.
Incident playbooks and scripts - RG incidents/notifications.
Regulatory reports and formats - uploads and receipts.
Code of Ethics and Conduct - correct communications.
Staff Compliance Awareness/AML Training - CS/CRM/Risk Training.
Anti-corruption policy - interaction with registers/bodies.

19) Implementation plan (30 days)

Week 1

1. Approve SE/interlock policy (types, timing, cooling, communications).
2. Specify data/event model and RACI.
3. Prepare UX layouts and texts (key locales).

Week 2

4. Implement constraint APIs and suppression loops (games/PSP/CRM).
5. Connect SE registers; configure format/bill validators.
6. Train CS/CRM; release scripts and FAQs.

Week 3

7. Pilot (5-10%): blocking checks, deposit attempts, misalignments.
8. Cooling/reactivation tests, manual validation of cases.
9. Collect feedback, update texts/rules.

Week 4

10. Full release; monitoring KPIs and Sinka alerts.
11. Report to management; CAPA for deviations.
12. Plan v1. 1: expansion of local integrations/registries, additional scenarios.

What to do tomorrow cheat sheet (for CS/CRM)

For any self-exclusion request → activate SE immediately and send a confirmation.
Never suggest "change your mind"; do not give bonuses/discounts.
Check marketing suppression and deposit block.
Answer any question about the delay in conclusions neutrally ("security check").
Record all actions with the ID of artifacts/receipts.