UX комплаєнс-дашбордів
1) Призначення та принципи
Комплаєнс-дашборд - це «верхній шар» контролю регуляторних ризиків (KYC/AML, відповідальна гра, санкції/РЕР, RTP/сертифікація, захист даних), який:- дає сигнали і пріоритизує ризики;
- забезпечує пояснюваність («чому спрацювало»);
- прискорює реакцію (кнопки дії, маршрути ескалації);
- зберігає сліди аудиту (хто і коли що зробив).
- 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% = флагованих за поведінковими правилами/активні гравці.
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 і «очікувані наступні кроки»;
- «схожі кейси/рішення»;
- «обґрунтування закриття» і шаблони репортів.
- неможливість закрити кейс без заповнених полів обґрунтування;
- попередження при невиконанні кроків 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%; аномалія по ринку.
- компактна картка (тип, джерело, впевненість, наслідки), 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, а потім розширюйте до звітності та політики версіонування - так дашборд стане реальним інструментом зниження ризиків, а не просто вітриною цифр.