GH GambleHub

UX комплаєнс-дашбордів

1) Призначення та принципи

Комплаєнс-дашборд - це «верхній шар» контролю регуляторних ризиків (KYC/AML, відповідальна гра, санкції/РЕР, RTP/сертифікація, захист даних), який:
  • дає сигнали і пріоритизує ризики;
  • забезпечує пояснюваність («чому спрацювало»);
  • прискорює реакцію (кнопки дії, маршрути ескалації);
  • зберігає сліди аудиту (хто і коли що зробив).
Принципи UX:
  • Signals over raw: спочатку статуси/аномалії, потім деталі.
  • Time-to-decision <60 сек: пресети фільтрів, короткі резюме кейса, швидкі дії.
  • Explain & Next: поруч з сигналом - «що це» і «що далі».
  • Єдина шкала критичності: Info/Low/Medium/High/Critical з колірною консистентністю.
  • Фіксована таймзона і вікно аналізу, явна дата генерації звіту.
  • Нульовий витік ПДн: мінімум PII; за замовчуванням - псевдоніми/хеші.

2) Ролі та ключові сценарії

Head of Compliance: огляд ризиків, навантаження, SLA розслідувань, прогрес remediation.
Комплаєнс-аналітик (L1/L2): тріаж алертів, кейс-менеджмент, підготовка доказової бази.
AML Officer: підозрілі транзакції, SAR/STR підготовка, списки санкцій/РЕР.
RG (Responsible Gaming): поведінкові патерни ризику, ліміти/самовиключення, інтервенції.
Data Protection Officer (DPO): DSAR, витоки, анонімізація, доступи.
Tech/QA: стабільність інтеграцій провайдерів скринінгу, помилки/ретраї, латентність.
Legal: дедлайни регуляторних репортів, статуси аудит-файлів.

Типові сценарії:

1. «Критичні алерти за сьогодні» → розподілити по виконавцях.

2. «Прострочені кейси» → ескалувати.

3. «RTP вийшов за коридор» → заблокувати гру/оператора, завести розслідування.

4. «Збіг із санкційним списком» → KYC hold, запит документів.

5. «Високий ризик RG» → м'яка/жорстка інтервенція, заморожування депозитів.

3) Інформаційна архітектура

1. Глобальна панель: період, гео/юрисдикція, бренд/оператор, продукт, критичність, статус кейса, виконавець.
2. Головна («Сьогодні»): зведення KRI/KCI, алерти, burn-down SLA, «top movers».
3. Ризики (Risk Hub): матриця категорій (KYC/AML/RG/Privacy/Certification/Payments).
4. Кейси: черга, Kanban/таблиця, шаблони рішень, історія дій.
5. Звітність: регуляторні звіти, дедлайни, статус файлів і валідацій.
6. Інтеграції: здоров'я провайдерів (санкції, PEP, документ-верифікація, поведінковий скоринг).
7. Політики та контроль: версії правил, чейнджлог, експерименти/пісочниці.

4) Метрики: KRI, KCI и SLA

4. 1 KRI (Key Risk Indicators)

Sanctions/PEP Hit Rate = hits/перевірки.
False Positive Rate = помилкові збіги/всі збіги.
Unverified Users% = незавершили KYC/все нові.
SAR/STR per 1k Users = кількість SAR/STR/1000 користувачів.
RG High-Risk% = флагованих за поведінковими правилами/активні гравці.

RTP Deviation =набл _ RTP − теор _ RTP.

4. 2 KCI (Key Control Indicators)

KYC Turnaround (p50/p95) - медіана/квантиль часу верифікації.
Alert → Case Conversion% - частка сигналів, що стали кейсом.
Case Resolution Time (p50/p95).
Investigation Reopen% - частка повторно відкритих кейсів.
Data Access Violations - спроби несанкціонованого перегляду ПДн.

4. 3 SLA/SLO (операційні)

Triage SLA: критичний алерт взято в роботу ≤ 15 хв.
Resolution SLA: за типами (KYC - 24ч, AML - 72ч, RG - 24ч, інцидент privacy - 72ч).
Provider Uptime/Latency: скринінг-ендпоінти p95.
ETL Freshness: лаг вітрин даних ≤ X хвилин.

5) Віджети і патерни

Головна («Сьогодні»)

Heatmap ризиків: категорії × критичність; клікабельно до списку кейсів.
SLA Burn-down: скільки кейсів в зеленій/жовтій/червоній зоні по дедлайнах.
Top Movers: метрики, що змінилися> порогу (FPR, RG High-Risk%, RTP Dev).
Provider Health: аптайм, затримки, помилки щодо інтеграцій.

Risk Hub

Матриця «категорія × юрисдикція» з підказками політик і локальних вимог.
Anomaly Explainers: внесок ринків/ігор/провайдерів у відхилення метрики.
Drill-through: від агрегату → до списку подій → до картки користувача (без PII, тільки псевдо-ID).

Кейси

Картка кейса: статус, критичність, чек-лист, остання активність, власник, SLA-таймер, «Чому спрацювало правило».
Action bar: «Запросити документ», «Поставити ліміт», «Hold/Unhold», «Ескалувати», «Закрити з результатом».
Audit Trail: незмінний лог, вкладення, лінки на правила/події.
Шаблони рішень (playbooks): попередньо заповнені кроки і тексти повідомлень.

Звітність

Календар дедлайнів: регуляторні звіти, підписи, підтвердження.
Валідатор: статуси перевірок файлів/схем, помилки та виправлення.
Експорт: версії файлів з хешами, підпису часу і відповідальних.

6) Правила, пояснюваність і версії

Rule Catalog: список правил (ID, версія, власник, юрисдикції, опис логіки).
Explainability: поруч з тригером - "які факти призвели до спрацьовування" (наприклад, "збіг за санкційним аліасом, джерело: EU-лист").
Versioning: правило вказує точну версію моделі/списку; кейс зберігає снапшот логіки.
Scenario Testing: «прогін на історії» для свіжої версії перед включенням.
Change Log: хто змінив, що змінив, чому (лінк на тікет).

7) Дані та контракти

Мінімальний контракт подій:
  • `kyc_check` (user_pid, provider, result, reason_codes, ts).
  • `sanctions_screen` (user_pid, list_name, match_score, match_fields, ts).
  • `rg_signal` (user_pid, risk_level, features_snapshot, ts).
  • `rtp_sample` (game_id, market, spins, rtp_observed, window, ts).
  • `case_event` (case_id, action, actor, ts, payload_ref).
  • `privacy_incident` (type, scope, status, ts).
Вітрини:
  • Daily_Risk (категорія × день × юрисдикція).
  • Case_Flow (SLA/етапи/результати).
  • Provider_Health (аптайм/latency/помилки по інтеграціях).
  • Rule_Versions (активні/відкликані).
Якість даних:
  • обов'язкові поля, допустимі діапазони, ідемпотентність подій, дедуплікація, моніторинг лагів.

8) Приватність, RBAC і PII-мінімізація

Рольова модель: Legal/Head бачать агрегати і кейси, L1 - знеособлені картки, доступ до PII - тільки по justify-кнопці з журналюванням.
Типовий PII-режим: приховані ПІБ/адреси; показуються тільки псевдо-ID/маски.
Just-in-Time Access: тимчасовий доступ до PII за кейсом; авто-відгук.
Data Lineage: шлях поля від джерела до вітрини; швидко перевірити законність обробки.
Export Guard: позначки біля експортів (PII/No-PII), попередити про порушення політики.

9) Процеси розслідувань (Case Ops)

Етапи: Detect → Triage → Investigate → Decide → Remediate → Report → Learn.

UX-підказки:
  • чек-листи за типами кейсів;
  • таймер SLA і «очікувані наступні кроки»;
  • «схожі кейси/рішення»;
  • «обґрунтування закриття» і шаблони репортів.
Guardrails:
  • неможливість закрити кейс без заповнених полів обґрунтування;
  • попередження при невиконанні кроків playbook;
  • автоматичний follow-up (через N днів) для перевірок ефективності міри.

10) Алерти та ескалації

Типові правила:
  • Critical: sanction true match; масове відхилення KYC провайдером; RTP Dev> δ при N спинах; витік ПДн.
  • High: RG High-Risk surge > Xσ; FPR санкційного скринінгу ↑ вище порогу; прострочення SLA.
  • Medium: затримка провайдера> p95 SLO; зростання reopen%; аномалія по ринку.
UX для алертів:
  • компактна картка (тип, джерело, впевненість, наслідки), 2 кнопки: «Взяти в роботу», «Відхилити з причиною».
  • масові дії для батч-алертів.
  • «Чому я це бачу» - власник політики/правила.
Ескалації:
  • матриця «тип ризику × рівень» → юридичний, exec, техпідтримка;
  • авто-ескалація при порушенні SLA.

11) Відповідальна гра (RG) - UX-специфіка

Ранні маркери: нічна активність, зростання депозитів, часті відміни висновків, chase-поведінка.
Віджети: RG Risk Funnel (маркер → контакт → ліміт/пауза → outcome), карта інтервенцій та їх ефективність.
Інтервенції: м'які (повідомлення, reality-check), жорсткі (ліміти, тайм-аут, самовиключення).
Обґрунтованість: поруч з картою заходів - «чому обрано цей рівень впливу».

12) Доступність та локалізація

контраст і шрифти по WCAG, передбачуваний фокус, гарячі клавіші;

локалізація термінів комплаєнсу (глосарій в UI);

єдині формати дат/чисел, явна валюта і часовий пояс;

«режим презентації» - екрани без PII для демонстрацій аудиту/раді директорів.

13) Антипатерни

«Стіна таблиць» без сигналів і пояснень.
Змішання ролей: юридичні дані доступні L1 без justify.
Спливаючі вікна на кожен клік (втома інтерфейсу).
Різні формули для однакових метрик в різних віджетах.
Безликі алерти без дії «що далі».
Експорт з ПДн без попередження і логування.

14) Чек-лист впровадження (за спринтами)

Спринт 1: базові вітрини (Daily_Risk, Case_Flow), головна «Сьогодні», матриця ризиків.
Спринт 2: картка кейсу + playbooks, SLA-таймери, audit trail.
Спринт 3: інтеграції провайдерів (санкції, KYC, RG), Provider Health, ретраї.
Спринт 4: звітність і валідатор, календар дедлайнів, експорт з guardrails.
Спринт 5: explainers, «схожі кейси», change-log правил, scenario testing.
Спринт 6: локалізація, доступність, режим презентації, JIT-доступ до PII.

15) Глосарій

KRI/KCI - індикатори ризику/контролю.
SLA/SLO - цільові/контрактні часи реакції/рішення.
PEP/Sanctions - політично значущі особи/санкційні списки.
SAR/STR - звіти про підозрілу активність.
RG - відповідальна гра.
FPR/TPR - хибнопозитивна/істиннопозитивна частки.
PII - персональні дані.
Playbook - шаблон дій по кейсу.

16) Підсумок

Хороший UX комплаєнс-дашборд - це:

1. сигнали з пояснюваністю,

2. швидкі та безпечні дії,

3. строгий контроль доступу і сліди аудиту,

4. консистентна метрика на всіх екранах,

5. підтримка процесів розслідувань і звітності.

Починайте з «Сьогодні» (сигнали, SLA, здоров'я інтеграцій), додавайте Case Ops і Explainability, а потім розширюйте до звітності та політики версіонування - так дашборд стане реальним інструментом зниження ризиків, а не просто вітриною цифр.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Telegram
@Gamble_GC
Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.