Проверка финансовой доступности игрока

Проверка финансовой доступности игрока (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-тренинги и обучение сотрудников / Осведомленность персонала о комплаенсе
Уведомления о нарушениях и сроки отчетности
Регуляторные отчеты и форматы данных
Внутренний аудит и внешний аудит / Аудиторские чек-листы

Проверка финансовой доступности игрока