Перевірка фінансової доступності гравця

Перевірка фінансової доступності гравця (Affordability)

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

Забезпечити, щоб гра відповідала фінансовим можливостям гравця, знижуючи ризик шкоди і дотримуючись ліцензійних вимог. Affordability доповнює RG і AML: ми оцінюємо здатність гравця нести витрати на гру без шкоди (не плутати з перевіркою походження коштів, хоча кейси часто перетинаються).

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

2) Принципи

Пропорційність: глибина перевірки відповідає рівню ризику і ринку.
Мінімально необхідна інформація: запитуємо тільки те, що потрібно для вирішення.
Прозорість і повага: зрозумілі причини запиту та очікувані документи/терміни.
Без tipping-off AML: у формулюваннях уникаємо натяків на підозри.
Доказовість: всі кроки і рішення зафіксовані, артефакти підшиті.
Privacy-by-design: GDPR/локальні аналоги, зберігання і доступ по RBAC.

3) Ролі та RACI

Affordability Owner (RG Lead/Risk Lead) - політика, пороги, ескалації. (A)

Risk Analysts (1-а/2-а лінії) - перевірка, запит доказів, рішення. (R)

CS/CRM - комунікації, супровід гравця, SLA відповідей. (R)

Payments/Finance - блок/ліміт депозитів/висновків на час перевірки. (R)

Compliance/Legal/DPO - відповідність ринкам, приватність, шаблони. (C)

Data/Engineering - події/логи, інтеграції (банківські API, верифікатори). (R)

Internal Audit - незалежна оцінка практик і вибірок. (C)

Exec Sponsor (COO/CEO) - ресурси, «tone from the top». (I/A)

4) Тригери для запуску перевірки (скелет)

Фінансові:

Великий разовий депозит (поріг по ринку).
Швидке зростання суми депозитів/втрат за короткий період.
Часта відміна висновків; перехід на «позикові» платіжні методи.

Поведінкові/маркерні:

Нічні/тривалі сесії, прискорення ставок, множинні RC без перерви.
Повідомлення гравця про фінансові труднощі.

Регуляторні/профільні:

Досягнення порогів, що вимагають EDD/affordability по ринку/ліцензії.
Підвищений ризик-клас (швидкі RG/AML).

5) Дані та докази (рівні)

Рівень A - Легка перевірка (мінімум):

Самодекларація бюджету на розваги/доходів (форма в продукті).
Зведені банківські/фінтех-виписки (без зайвих деталей) або довідка про доходи.
Підтвердження зайнятості/статусу (за бажанням ринку).

Рівень B - Стандарт:

Банківські виписки за 90 днів (замазані поля, що не відносяться).
Документи про доходи: довідка роботодавця, податкова форма, контракт/інвойси (для самозайнятих).
Декларація витрат за основними категоріями (житло/кредити/аліменти).

Рівень C - Поглиблена (EDD/SoW при необхідності):

Підтвердження джерела коштів/активів (продаж майна, дивіденди тощо).
Відкрите банківське API (open banking) - агреговані метрики платоспроможності (за згодою і допустимості).
Доп. документи на вимогу ринку/регулятора.

💡 Завжди діємо за принципом data minimization: не зберігаємо зайве, маскуємо невикористовуване.

6) Оцінка та порогові значення

Net Disposable Income (NDI): оціночний «вільний» дохід після базових витрат.
Affordable Loss/Budget: частка NDI, допустима під розвагу (внутрішня політика + локальні норми).

Класи рішень:

Green - відсутність обмежень або м'який бюджет.
Amber - ліміти на депозити/втрати, моніторинг.
Red - відмова/жорсткі ліміти/тайм-аут/SE.

Приклад шкали (ілюстративно, валідувати по ринках):

Втрати> X% оціночного NDI в 30 днів → Amber.
Втрати> Y% NDI або токсичні маркери → Red.

7) Процес (від сигналу до рішення)

Крок 1 - Сигнал і попередній скоупінг. Збір фактів (суми/час, маркери RG), присвоєння пріоритету (S1.. S3), фіксація в кейс-системі.
Крок 2 - Запит доказів. Вибір рівня (A/B/C), зрозумілий список документів, дедлайн (зазвичай 7-14 днів), тимчасовий ліміт/пауза при необхідності.
Крок 3 - Аналіз. Розрахунок NDI/бюджету, перевірка стійкості доходів/витрат, крос-перевірка з поведінкою.
Крок 4 - Рішення. Green/Amber/Red, встановлення лімітів/блокувань, терміни перегляду.
Крок 5 - Комунікація. Нейтральні тексти без тиску, без AML-підтексту.
Крок 6 - Документація. Артефакти, розрахунки, rationale, посилання на політики/локальні норми.
Крок 7 - Ревізія. Повторний огляд через N днів або при зміні ризиків.

8) UX і коректні тексти

Запит документів (нейтрально):

💡 Ми хочемо переконатися, що витрати на гру залишаються комфортними для вас. Будь ласка, завантажте короткі підтвердження доходів/бюджету (список всередині). Це допоможе підібрати відповідні ліміти.

Тимчасове обмеження на період перевірки:

💡 На час перевірки ми обмежимо депозити. Це стандартна міра безпеки. Після завершення перевірки ви отримаєте повідомлення.

Рішення Amber:

💡 За результатами перевірки ми встановили ліміти депозитів/втрат, щоб ваші витрати залишалися в рамках бюджету. Ви можете переглянути їх через [дата].

Рішення Red:

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

Уникати формулювань про підозри/AML; використовувати нейтральні «перевірка безпеки/комфортності витрат».

9) Взаємодія з RG і AML

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

10) Приватність, права і ретенція

Основа обробки: правовий обов'язок/законний інтерес (збереження гравців і дотримання ліцензії).
Мінімізація та маскування: збір тільки необхідного, EXIF видаляється, чутливі поля закриваються.
Доступ: RBAC/ABAC, журнали читання/змін, WORM-сховище артефактів.
Ретенція: зазвичай 5-7 років або по ринку/ліцензії; після закінчення - безпечне видалення.
Права суб'єктів: DSAR через DPO; не розкривати методики антифроду/скорингів і дані третіх осіб.

11) Дашборд і метрики

Time-to-Decision (TTD): медіана від сигналу до рішення.
Completion Rate: % кейсів з отриманими документами вчасно.
Amber/Red Rate: частки рішень по сегментах/ринках.
Repeat Harm Markers: маркери шкоди в 30/90 днів після рішення.
Limit Uptake/Adherence: частка дотримання лімітів.
Complaints & Resolution: скарги/термін закриття.
Data Sufficiency: % кейсів, де зібрано мінімальний набір доказів.
Auditability: частка кейсів з повним пакетом артефактів і розрахунком NDI.

12) Чек-листи

Перед запуском політики

Порогові значення по ринках узгоджені з Legal/Compliance.
Шаблони листів локалізовані і перевірені на нейтральність.
Інтеграції зі сховищем документів, open-banking (де доступно), кейс-системою.
Процедури маскування/видалення EXIF, валідації форматів.
Скрипти CS/FAQ підготовлені; навчання завершено.

В операціях

Кожен кейс має пріоритет, список необхідних документів і дедлайн.
Тимчасові ліміти/блокування активуються автоматично.
Рішення документуються з розрахунками та посиланнями на політику.
Суміжні прапори RG/AML/marketing suppression включені.

Аудит і поліпшення

Квартальна вибірка кейсів (≥ 30) на повноту/логічність рішень.
Звірка логу подій з гаманцем/GL.
CAPA за повторюваними зауваженнями.

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

A) Список документів (рівень B)

💡 Будь ласка, надайте: (1) виписки за 90 днів (можна приховати не пов'язані операції), (2) підтвердження доходів (довідка/контракт/форма), (3) за наявності - підтвердження регулярних витрат (іпотека/оренда).

B) Нагадування про дедлайн

💡 Нагадуємо про запит документів щодо перевірки фінансової доступності. Дедлайн - [дата]. Якщо потрібні роз'яснення - дайте відповідь на це повідомлення.

C) Рішення з лімітами

💡 За підсумками перевірки встановлено денний ліміт депозитів € X і місячний ліміт втрат € Y до [дата перегляду]. Це допоможе зберегти витрати в рамках вашого бюджету.

D) Закриття без документів

💡 Ми не отримали документи до [дата]. Щоб уникнути можливої шкоди, ми обмежимо депозити/гру. Ви можете надати документи для перегляду.

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

Події: `affordability_triggered`, `docs_requested`, `docs_received`, `affordability_decision{green|amber|red}`, `rg_limits_set`, `marketing_suppressed`.
API кейс-системи: `POST /affordability/case`, `PATCH /case/{id}/status`, `POST /case/{id}/decision`.
Сховище документів: шифрування at-rest; автоматичне маскування, EXIF-стрипінг; контрольні суми та WORM-журнали.
Правила (policy engine): пороги по ринках, SLA, автоліміти на період перевірки.
Звітність: вивантаження CSV/JSON з агрегатами без PII.

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

Надлишкові запити документів. → Рівні A/B/C, мінімізація, пояснюємо «навіщо».
Затримки без тимчасових заходів. → Автоліміти при відкритті кейса.
Нечіткі тексти → Готові шаблони, тестування на зрозумілість.
Змішування з AML в листах. → Нейтральні формулювання, окремий AML-кейс при необхідності.
Відсутність розрахунків. → Стандартизувати метод NDI/бюджету і зберігати калькуляцію.
Неповна синхронізація. → Зв'язати рішення з CRM/PSP/ігровими провайдерами (suppress/blocks).

16) Регіональні профілі (каркас для заповнення)

Для кожного ринку фіксувати: обов'язкові пороги, джерела даних, допустимість open-banking, терміни реакції, формати звітності, вимоги до зберігання/локалізації.


Profile [Market]
Thresholds:...
Sources: self-declaration     banking API      docs
Terms: ack ≤...; decision ≤ …
Solutions: green/amber/red - parameters
Reporting: Frequency/Format
Privacy: local requirements

17) 30-денний план впровадження

Тиждень 1

1. Затвердити політику affordability і пороги по ринках.
2. Узгодити шаблони комунікацій (RU/EN + локалі) і FAQ.
3. Специфікувати події/модель даних та інтеграції (кейси, сховище, open-banking де доступно).

Тиждень 2

4. Реалізувати кейс-флоу, автоліміти на період перевірки, завантаження/маскування документів.
5. Підключити suppression маркетингу/PSP при активному кейсі.
6. Навчити Risk/CS; випустити 1-сторінкові та макроси.

Тиждень 3

7. Пілот (5-10%): замір TTD/Completion/Complaints, ручна ревізія рішень.
8. Внести коригування в пороги/тексти, налагодити інтеграції.

Тиждень 4

9. Повний реліз; щоденний моніторинг KPI і вибіркові рев'ю.
10. Звіт керівництву; CAPA за збоями і скаргами.
11. План v1. 1: розширити профілі ринків, додати open-banking/скоринги, автоматичний розрахунок NDI.

Пов'язані розділи:

Відповідальна гра та ліміти
Самовиключення і блокування акаунтів
Reality Checks та ігрові нагадування
Інцидентні плейбуки та сценарії (RG/AML)
AML-тренінги та навчання співробітників/Обізнаність персоналу про комплаєнс
Повідомлення про порушення та терміни звітності
Регуляторні звіти та формати даних
Внутрішній аудит і зовнішній аудит/Аудиторські чек-листи

Перевірка фінансової доступності гравця