Операции и Комплаенс → Регуляторная карта iGaming-рынков

Регуляторная карта iGaming-рынков

1) Зачем нужна регуляторная карта

Работа на нескольких рынках упирается в сравнимость и актуальность требований. «Карта» — это единый каталог стран с нормализованными полями: тип лицензии, требования KYC/AML, RG-ограничения, правила рекламы/аффилиатов, платежные методы, налоговая модель, отчетность, провайдеры и локальные «красные линии».

• Ускорить go-/no-go и приоритизацию стран.
• Упростить on-boarding провайдеров, рекламу и платежи под местные нормы.
• Снизить штрафные/репутационные риски и стоимость комплаенса.
• Давать Ops/Compliance единый источник правды (SSOT).

2) Таксономия полей (что фиксируем по каждой стране)

Базовые метаданные

Страна/регион, статус рынка (регулируется/серый/запрещен), доступные вертикали (casino, live, betting, poker, lotto).
Модель входа: локальная лицензия /.com ограничен / партнерство с локальным держателем.

Лицензирование и надзор

Регулятор(ы), типы лицензий (B2C/B2B/суб-категории), требования к локальному присутствию.
Процедуры аудита (технический, финансовый, RNG) и периодичность.

KYC/AML

Базовая проверка (identity, address), EDD-триггеры, проверка PEP/санкций, сроки хранения данных.
Правила источника средств, velocity-ограничения и эскалации.

Responsible Gaming (RG)

Возрастные ограничения, лимиты депозита/проигрыша/времени, самоисключение, cooling-off, локальные реестры.

Реклама и аффилиаты

Разрешенные каналы/временные слоты/викидки контента, возрастные маркеры, запреты на «безрисковые» формулировки.
Требования к аффилиатам (договоры, раскрытия, реальные UTM, черные списки практик).

Платежи и провайдеры

Разрешенные методы (карты, банки, кошельки, ваучеры), локальные процессоры, требования к чарджбэкам/возвратам.
Требования к B2B-провайдерам игр/платежей (лицензии, отчетность, SLA).

Данные/Privacy и безопасность

Режим персональных данных (GDPR-подобные нормы/локальные).
Локализация/трансграничная передача, сроки хранения, права субъекта данных.

Налоги и отчетность

Налоговая база (часто GGR/turnover/платежные сборы), отчетные периоды, форматы выгрузок.
Финмониторинг, обязательные отчеты RG/AML, инцидент-репортинг.

Ограничения и «красные линии»

Черные/серые практики маркетинга, запреты на бонусные механики, лимиты джекпотов, ночные ограничения и пр.

3) Модель данных (каркас)

yaml country: <ISO-2>
market_status: regulated    restricted    prohibited    grey verticals: [casino, live, betting, poker, lotto]
entry_model: local_license    partner. com_limited regulator:
name: <...>
site: <ref>
licenses:
b2c: [<type_a>, <type_b>]
b2b: [<rng>, <platform>, <payment_provider>]
kyc_aml:
base: [id, address, pep_sanctions]
edd_triggers: [amount_spike, multiple_methods, high_risk_geo]
retention_days: <int>
rg:
limits: {deposit: required    optional, loss: required    optional, time: optional}
self_exclusion: registry    internal    none ads_affiliates:
allowed_channels: [tv, ooh, digital, influencer]
disclaimers_required: true    false affiliate_rules: [kyb_required, utm_registry]
payments:
methods_allowed: [cards, bank_transfer, wallet, voucher, cash]
withdrawals_rule: source_to_source    required_checks privacy_security:
regime: gdpr_like    local data_localization: required    not_required tax_reporting:
tax_model: ggr    turnover    mixed reporting: {frequency: monthly    quarterly    realtime, formats: [csv, api]}
providers:
game_providers_requirements: [license, testing, rng]
payment_providers_requirements: [local_presence, settlement_rules]
red_lines: [no_risk_free_claims, minors_targeting_ban]
last_review: YYYY-MM-DD owner: compliance_team

4) Карта рисков и приоритизация стран

• Regulatory Risk (жесткость/неопределенность/штрафы).
• Go-To-Market Effort (сроки лицензий/локализация/интеграции).
• Unit Economics (налоговая нагрузка/платежные комиссии/ARPPU прогноз).
• Operational Complexity (RG-ограничения/отчетность/вендоры).

Скоринг (пример): `Score = (Economics – Risk – Complexity) × Readiness`, где Readiness — зрелость наших процессов (KYC/AML/RG/Reporting) под конкретную юрисдикцию.

Кластеры приоритета: A (запуск 6–9 мес), B (подготовка), C (исследование).

5) Матрица соответствия (conformance map)

6) Controls-/Policy-as-Code (фрагменты)

yaml control_id: RG-LIM-DAILY judgments: [""] # defaults, redefined in trigger country: loss_today> limit_loss_daily actions:
- block: betting
- notify: player_template_rg_7 overrides:
- when: country==<ISO>
set: {limit_loss_daily: <local_rule>, cool_off_hours: <N>}

yaml policy_id: ADS-DISCL-001 require:
- on_all_creatives: age_restriction
- on_bonus: wagering_conditions ban:
- wording: ["risk-free", "guaranteed win"]
overrides:
- country: <ISO>
additions: {time_window: "22:00-06:00 ban TV"}

yaml reporting:
frequency: monthly exports: [revenue_by_vertical, rg_cases, aml_sar]
transport: sftp    api overrides:
- country: <ISO>
frequency: realtime exports: [bet_level, session_level]

7) Дашборды регуляторной карты (что показывать)

Market Readiness: статус лицензирования/интеграций/политик по странам.
Compliance Heatmap: KYC/AML/RG/Ads/Privacy — «зеленый/желтый/красный».
Evidence Coverage: доля операций с корректно собранными доказательствами.
Reporting SLA: своевременность выгрузок/ошибки схем/валидации.
Risk Register: топ-риски по странам, план смягчения, ETA.

8) Процессы и RACI

SOP: Добавление или обновление страны

1. Юр-оценка и mаппинг требований → карточка страны.
2. Настройка Policy-/Controls-as-Code и отчетности.
3. Провайдеры/платежи: due diligence и тесты.
4. Battle-test на стейдже → пилот 1–5% трафика.
5. Ввод в эксплуатацию + мониторинг KPI и регуляторных алертов.

9) Чек-листы due diligence

Новая страна

• Регулятор и тип лицензии, вертикали разрешены.
• KYC/AML/RG маппинг и overrides в контролях.
• Ads/Affiliates правила и шаблоны оговорок.
• Privacy/локализация данных, сроки хранения.
• Платежи: доступные методы, правила возвратов/выводов.
• Отчетность: форматы, транспорт, частоты; тест-выгрузка.
• Провайдеры: требования и аудит.
• Риски/«красные линии» зафиксированы.

Новый аффилиат/канал

• KYB, договор, UTM-реестр, библиотеки креативов.
• Ограничения таргетинга (возраст/гео).
• Политика claim-ов и запрещенных формулировок.
• Механизм приостановки трафика при нарушениях.

10) Анти-паттерны

«Две версии правды»: Excel-таблицы отдельно от прод-контролей.
Неверифицированные локальные интерпретации без юр-подтверждения.
Универсальные правила рекламы без country-overrides.
Отсутствие evidence-хранилища и SLA отчетности.
Карта без владельцев и регулярной ревизии.

11) Метрики зрелости

Coverage стран: карточки стран с заполненными полями ≥ 90%.
Controls Alignment: доля контролей с country-overrides, где нужно ≥ 95%.
Reporting SLA: своевременность выгрузок ≥ 98%.
Evidence Completeness: заполненность наборов доказательств ≥ 98%.
Audit Findings TTR: закрытие замечаний ≤ 90 дней.
Incident Leakage: доля маркетинговых/RG нарушений → тренд к снижению.

12) Интеграции

Docs-/Policy-/Controls-as-Code: единый репозиторий с ревью/CI-линтом.
CRM/Payments/DWH: country-aware правила, отчетные витрины.
Observability: алерты на дрейф соблюдения (контроль не сработал, отчет не ушел).
AI-помощник комплаенса: поиск по карточкам стран, подсказки по overrides и черновики отчетов.

13) 30/60/90 — план внедрения

• Утвердить таксономию полей и шаблон карточки страны.
• Развернуть репозиторий «reg-map/» (docs/policies/controls/reports).
• Занести 5–7 ключевых стран на текущий портфель, настроить базовые overrides.
• Поднять дашборды Coverage/Heatmap/Reporting SLA.

• Добавить платежные/рекламные/провайдерские реестры и связки.
• Включить evidence-хранилище для RG/AML/Ads.
• Автоматизировать тест-экспорт отчетности и валидации схем.
• Встроить алерты на регуляторные «дрейфы».

• Покрыть ≥ 90% целевых стран, провести внутренний аудит дизайна контролей.
• Связать KPI регуляторной карты с OKR (Reporting SLA, Evidence, Audit TTR).
• Регулярные квартальные обновления карточек стран и процессов.

14) FAQ

Q: Как поддерживать актуальность карты?
A: Ревизия карточек раз в 90–180 дней, CI-напоминания по `last_review`, алерты на несоответствия отчетности/контролей.

Q: Что делать при противоречиях между нормами стран?
A: Применять более строгую норму или разделять продуктовые флоу по гео с отдельными overrides.

Q: Как связать карту с продуктом?
A: Через Controls-as-Code: правила включаются по `country`/`brand`/`vertical`, а отчетные витрины автоматически собирают нужные поля.