Самовиключення і блокування акаунтів

1) Мета і область

Забезпечити безпечні, прозорі і юридично коректні механіки самовиключення і блокувань для захисту гравців, зниження шкоди і дотримання ліцензійних вимог. Охоплення: веб/мобайл, провайдери ігор, платежі/PSP, CRM/маркетинг, саппорт (CS), Risk/AML, Legal/DPO, звітність регуляторам.

2) Принципи

Пріоритет безпеки гравця. Будь-який запит на SE обробляється негайно.
Ніякого тиску. Заборонені спроби переконати/реактивувати під час SE.
Незворотність в періоді. Зняття або пом'якшення - тільки після періоду охолодження і підтвердження.
Повнота блокування. Гра/депозити/маркетинг/бонуси/PSP - під suppression.
Доказовість. Логи рішень, артефакти, квитанції відправок до реєстрів.
Приватність. PII мінімізується, доступ по RBAC, зберігання по ретенції.

3) Ролі та RACI

RG Lead (власник процесу) - політика/метрики, ескалації. (A)

CS/CRM - прийом заявок, коректні комунікації, запуск suppression. (R)

Risk/AML - примусові блокування при ризиках/маркерах шкоди/санкціях. (R)

Product/UX/Engineering - UX-потоки, API SE/блокувань, інтеграції з реєстрами/провайдерами/PSP. (R)

Legal/DPO - локалізація вимог, приватність/ретенція. (C)

Payments/Finance - hold/скасування депозитів/висновків по політиці. (R)

Internal Audit - незалежні перевірки і CAPA. (C)

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

4) Типи обмежень

4. 1 Добровільні

Тайм-аут (cool-off): 24 год/7/30 днів.
Самовиключення (SE): 6-12 місяців, або безстроково; реактивація можлива тільки за процедурою (охолодження + підтвердження).

4. 2 Примусові

Блокування RG: при підтверджених маркерах шкоди/неналежній поведінці.
Юридичне блокування: на вимогу регулятора/суду/реєстру.
AML/санкційне блокування: щодо політики AML/санкцій (без tipping-off).

Загальне: при будь-якому активному обмеженні - повний suppression ігор/депозитів/маркетингу/бонусів.

5) UX-потоки і копірайт

5. 1 Ініціювання

З профілю та хедера: «Зробити перерву »/« Самовиключитися». ≤ 3 кліків.
Зрозумілі терміни та наслідки (гра/депозити/бонуси/комунікації).

5. 2 Підтвердження

Чіткий екран з типом/терміном/дата закінчення/що буде відключено.
Чекбокс «Я розумію наслідки» і CTA: «Підтвердити самовиключення».

5. 3 Після активації

Блок інтерфейсів, скрін «самовиключення активно до [дата]».
Посилання на допомогу та ресурси підтримки.

5. 4 Пом'якшення/повернення

Доступно тільки після закінчення терміну + період охолодження (наприклад, 24-168 год), з підтвердженням рішення.

• «Ми призупинимо доступ до ігор до [дата], щоб ви могли зробити паузу».
• "Маркетингові повідомлення відключені. Ви можете включити їх після закінчення періоду"

6) Інтеграції та блокуючі контури

Реєстри самовиключень (нац ./рег.) : реєстрація/перевірка при вході та перед депозитом; синхронізація realtime або T + 1.
Провайдери ігор: подія'session _ stop', заборона нових сесій; статус SE транслюється в аггрегатор.
PSP/платежі: блок нових депозитів/ризик-відхилення; прапори SE в анти-фроді.
CRM/маркетинг: suppression-листи для e-mail/SMS/push/ретеншн-кампаній.
Афіліати: повідомлення про SE-статус для заборони таргетингу/реактивації.

7) Дані, журнали та ретенція

• `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`.

• Аудит дій: хто/коли/що встановив, спроби гри/депозиту під час SE.
• Підтвердження: квитанції реєстрації в реєстрах, ID кейсів.

Ретенція: не менше терміну, необхідного регуляторами (часто 5-7 років); доступ строго по RBAC/ABAC.

8) Маркери шкоди та примусові заходи

Фінанси: швидке зростання втрат/депозитів, скасування висновків, кредитні методи.
Поведінка: нічні марафони, зростання швидкості ставок, повторні «майже ліміт».
Комунікації: прохання прибрати ліміти, ознаки фінансових труднощів.
Соціальні сигнали: «граю, щоб закрити борги».

Ескалації: від м'яких контактів → тимчасові обмеження → RG-блокування → (при необхідності) повідомлення регулятора/реєстру.

9) Платежі та висновки

Нові депозити заборонені при будь-якому активному обмеженні.
Висновки: обробляються за політикою (чесне повернення балансу, перевірка AML/RG, відсутність tipping-off).
Chargeback/диспути - згідно з договором і законами; документація обов'язкова.

10) Комунікації (без тиску і tipping-off)

Підтвердження SE: "Ваше самовиключення активно до [дата]. Ми відключили доступ до ігор і розсилок, щоб ви могли зробити паузу"

Спроба входу при SE: "Аккаунт обмежений до [дата]. Ось ресурси підтримки та інформація про терміни"

Запит на дострокове повернення: "Пом'якшення обмежень можливе тільки після періоду охолодження.
AML-блокування: використовувати нейтральні формулювання «стандартні перевірки безпеки», без вказівок на підозри.

11) Звітність та відповідність

Календар дедлайнів відправки подій/реєстрів; верифікація квитанцій.
Формати звітів (CSV/XML/JSON/XLSX) і контроль схем (валідатори).
Звірка даних: гаманець/GL ↔ звіти RG/реєстр SE; розбіжності> X% - інцидент.
Зберігання підтверджень про прийом звітів регулятором.

12) Дашборд і KPI/KRI

SE Coverage: частка активних SE/тайм-аутів.
Time-to-Block: медіана від запиту гравця до фактичного блокування (мета - миттєво).
Suppression Integrity: % гравців з SE, у кого відключені всі канали маркетингу/депозитів.
Attempts During SE: число спроб входу/депозиту - контроль UX та інформування.
Return After Cooldown: частка повернень після закінчення SE і їх поведінка.
Registry Sync SLA: своєчасність синхронізацій/підтверджень.
Complaints/Disputes: звернення по SE, частка вирішених ≤ X днів.
Audit Findings / Repeat: повторювані недоліки.

13) Чек-листи

Перед запуском

• UX-потоки «тайм-аут/SE/реактивація» ≤ 3 кліків; тексти узгоджені.
• Інтеграції: реєстри SE, провайдери ігор, PSP, CRM-suppression.
• Логи незмінні, валідатори схем звітності в CI.
• Скрипти CS і FAQ опубліковані; команда навчена.
• Політика ретенції/приватності (DPO) затверджена.

Операції

• Будь-який запит на SE - миттєве застосування і квитанція.
• Пом'якшення - тільки після охолодження і підтвердження.
• Скарги/апеляції - реєструються і відповідаються в строк.
• Перевірки suppression у маркетингу/PSP - за розкладом.

Аудит і контроль

• Квартальні вибірки кейсів SE/блокувань та їх артефактів.
• Звірка з GL/гаманцем/CRM; розбіжності - CAPA.
• Ретро щодо інцидентів RG з оновленням політики.

14) Шаблони (швидкі вставки)

A) Підтвердження тайм-ауту

B) Підтвердження самовиключення

C) Відповідь на запит про дострокове зняття

D) Інформування афіліату

E) Повідомлення при спробі депозиту під час SE

15) Правові та приватність

Основи обробки: законні інтереси/правові зобов'язання для RG/SE; документообіг для звітності.
DSAR: надаються відомості без шкоди розслідуванням/захисту третіх осіб; дані SE - з урахуванням локальних норм.
Транскордонність: договірні гарантії та мінімізація.
Accessibility та локалізація: інтерфейси та листи мовою ринку, доступні формати.

16) Технічна реалізація (скелет)

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: правила охолодження, suppression, блок PSP/ігор.
DQ/Валідації: цілісність статусів в мультипровайдерному середовищі; консистентність звітів.
Моніторинг: алерти при розсинхронізації (реєстр/аггрегатор/PSP/CRM).

17) Часті помилки і як їх уникнути

Складні потоки SE. → скоротити кроки, винести в хедер/профіль.
Зняття обмежень без охолодження → enforce в Policy Engine.
Маркетинг «просочується». → єдиний suppression-прапор і nightly перевірки.
→ обов'язкові квитанції та лінки на ID реєстру.
Різні статуси у провайдерів/PSP. → періодичні звірки і авто-ремедіація.

18) Взаємозв'язки

Відповідальна гра і ліміти - політика і маркери шкоди.
Інцидентні плейбуки і сценарії - RG-інциденти/повідомлення.
Регуляторні звіти та формати - вивантаження та квитанції.
Кодекс етики і поведінки - коректні комунікації.
Обізнаність персоналу про комплаєнс/AML-тренінги - навчання CS/CRM/Risk.
Антикорупційна політика - взаємодія з реєстрами/органами.

19) План впровадження (30 днів)

Тиждень 1

1. Затвердити політику SE/блокувань (типи, терміни, охолодження, комунікації).
2. Специфікувати модель даних/подій і RACI.
3. Підготувати UX-макети та тексти (ключові локалі).

Тиждень 2

4. Реалізувати API обмежень і suppression-контури (ігри/PSP/CRM).
5. Підключити реєстри SE; налаштувати валідатори форматів/квитанцій.
6. Навчити CS/CRM; випустити скрипти і FAQ.

Тиждень 3

7. Пілот (5-10%): перевірки блокувань, спроб депозитів, розсинхронізацій.
8. Тести охолодження/реактивації, ручна валідація кейсів.
9. Зібрати фідбек, оновити тексти/правила.

Тиждень 4

10. Повний реліз; моніторинг KPI і алертів сінка.
11. Звіт керівництву; CAPA за відхиленнями.
12. План v1. 1: розширення локальних інтеграцій/реєстрів, додаткові сценарії.

Шпаргалка «Що робити завтра» (для CS/CRM)

При будь-якому запиті на самовиключення → відразу активуй SE і надішліть підтвердження.
Ніколи не пропонуй «передумати»; не давай бонуси/знижки.
Перевір suppression маркетингу і блок депозитів.
На будь-яке питання про затримку висновків відповідай нейтрально («перевірка безпеки»).
Всі дії фіксуй з ID артефактів/квитанцій.