Відповідальні платежі та ліміти гравців

1) Цілі та принципи

Захист гравця: запобігання шкоди (overspending/overplay), прозорість умов та інструментів самоконтролю.
Дотримання ліцензій: юрисдикційні вимоги до лімітів, cooling-off, self-exclusion, reality checks.
Фінансова стійкість: зниження чарджбеків/боргів/операційних ризиків, коректна оцінка affordability.
UX без тертя: легка установка/зміна лімітів, зрозумілі наслідки і таймінги, не заважаючи сумлінним.

2) Таксономія лімітів і захистів

2. 1. Ліміти гравця

Deposit limit (денний/тижневий/місячний).
Loss limit (чисті втрати за період).
Wager/Stake limit (оборот/макс ставка).
Time/session limit (хвилини гри/сеансу).
Velocity limit (частота депозитів/ставок).
Withdrawal frictions: cool-off перед повторними висновками, ліміти на частоту заявок.
Reality check: періодичні повідомлення про час/результат/баланс.

2. 2. Адміністративні заходи

Cooling-off (тимчасова пауза).
Self-exclusion (локальний/національний реєстр).
Affordability checks: оцінка фінансової доступності (доходи/зобов'язання/SoF).
KYC/SoF/SoW step-ups по порогах і поведінкових сигналах.

2. 3. Платіжно-комплаєнсні рамки

Same-method/Return-to-source: захист від перевитрати/« переведення в готівку ».
Net Deposits (ND): розріз депозитів/висновків, гейти на участь у промо/частина висновків.
Payout holds при ризиках (RG/AML), але з прозорим SLA і апеляціями.

3) Тригери та ескалації (risk-based)

Порогові суми (денний/30-денний оборот, великі депозити).
Поведінкові сигнали: нічна активність, швидкі повтори депозитів, низка soft-declines.
Гео/пристрій: зміна країни/ASN/VPN, «домогосподарство» з декількох акаунтів.
Платіжні ознаки: BIN-гео ≠ KYC, нові токени підряд, high-risk емітенти.
Результати RG-інструментів: часті reality-check dismiss, порушення власних лімітів.

Ескалації: попередження → жорсткі ліміти → cooling-off → self-exclusion → ручна оцінка affordability (SoF/SoW).

4) UX-патерни без зайвого тертя

Поверх усіх екранів - швидкий доступ до інструментів RG.
Майстер встановлення ліміту: період → тип ліміту → сума → набуття чинності.
Зміна ліміту: посилення - відразу; ослаблення - з відкладеним вступом (24-168 год).
Reality-check модалка: зрозумілі KPI (час/підсумок, депозити/висновки/результат), кнопки «продовжити »/» пауза».
Нормована мова: без засудження; короткі причини блоків («досягнутий денний ліміт депозиту»).
Локалізація та доступність: ICU-формати, a11y, RTL, великі шрифти.

5) Політика лімітів: псевдо-DSL

yaml policy: "rg_limits_v3"
limits:
deposit:
periods: [DAILY, WEEKLY, MONTHLY]
weaken_delay_hours: 72 loss:
periods: [DAILY, WEEKLY, MONTHLY]
weaken_delay_hours: 72 wager:
periods: [DAILY, WEEKLY]
stake_max:
amount: {EUR: 100}
reality_check:
interval_minutes_default: 60 show_metrics: [time_played, net_result, deposits, withdrawals]
cooling_off:
options: ["24h", "7d", "30d"]
immediate_effect: true self_exclusion:
registry: ["local", "national"]
triggers:
- if: net_deposits_30d > 2000 then: "affordability_check"
- if: deposit_velocity_24h >= 3 then: "hard_daily_deposit_cap"
- if: vpn_detected == true then: "deny_until_verified_geo"
payments:
same_method: true allow_nd_withdrawal: true

6) Інженерія та модель даних (мінімум)

rg. profiles (
user_id PK, kyc_level, risk_score, country, self_excluded BOOL, cooling_off_until TIMESTAMP
)

rg. limits (
user_id, type -- DEPOSIT    LOSS    WAGER    STAKE    TIME,
period -- DAILY    WEEKLY    MONTHLY    SESSION,
amount NUMERIC, currency TEXT, set_at TIMESTAMP,
weaken_effective_at TIMESTAMP, active BOOL,
PRIMARY KEY (user_id, type, period)
)

rg. events (
id PK, user_id, kind -- LIMIT_HIT    RC_SHOW    COOLING_ON    SEFLEX_ON    UNLOCK_REQ,
payload JSONB, created_at TIMESTAMP
)

rg. affordability (
user_id PK, status -- NOT_REQUIRED    REQUESTED    PASSED    FAILED    EXPIRED,
sof_required BOOL, sow_required BOOL, requested_at TIMESTAMP, decided_at TIMESTAMP
)

finance. net_deposits (
user_id, currency, nd_total NUMERIC, nd_30d NUMERIC, updated_at TIMESTAMP,
PRIMARY KEY(user_id, currency)
)

payments. activity_rollup (
user_id, day DATE, deposits NUMERIC, withdrawals NUMERIC,
wagers NUMERIC, losses NUMERIC, sessions_minutes INT
)

7) Контроль виконання (онлайн-перевірки)

На депозиті: перевірка DEPOSIT/Loss/Wager лімітів за періодами; velocity caps.
У грі: time/session і reality-checks за таймером; stake_max.
На висновках: ND-розріз, same-method, наявність cooling-off/self-exclusion.
При ослабленні лімітів: respect `weaken_effective_at`.
При тригерах affordability: блок «до перевірки» або обмеження лімітів.

8) SQL-шаблони

8. 1. Чи досягнутий денний депозитний ліміт

sql
WITH d AS (
SELECT COALESCE(SUM(amount),0) AS dep_day
FROM payments. activity_rollup
WHERE user_id=:uid AND day=CURRENT_DATE
)
SELECT (d. dep_day +:incoming_amt) <= l. amount AS allowed
FROM d, rg. limits l
WHERE l. user_id=:uid AND l. type='DEPOSIT' AND l. period='DAILY' AND l. active=true;

8. 2. Перевірка ND і статусів RG на виводі

sql
SELECT
(nd. nd_total >= 0) AS nd_ok,
(p. same_method_ok) AS same_method_ok,
(NOT pr. self_excluded) AS not_excluded,
(COALESCE(pr. cooling_off_until, now()) <= now()) AS not_in_cooling
FROM finance. net_deposits nd
JOIN payments. payout_context p ON p. user_id=nd. user_id AND p. currency=nd. currency
JOIN rg. profiles pr ON pr. user_id=nd. user_id
WHERE nd. user_id=:uid AND nd. currency=:ccy;

8. 3. Reality-check зріз

sql
SELECT user_id,
SUM(sessions_minutes) AS mins,
SUM(deposits) AS dep,
SUM(withdrawals) AS wd,
SUM(wagers - withdrawals + deposits) AS net_result
FROM payments. activity_rollup
WHERE user_id=:uid AND day BETWEEN CURRENT_DATE - INTERVAL '1 day' AND CURRENT_DATE;

8. 4. Запит на ослаблення ліміту і відкладений вступ

sql
UPDATE rg. limits
SET amount=:new_amount,
weaken_effective_at = now() + INTERVAL '72 hours'
WHERE user_id=:uid AND type='DEPOSIT' AND period='DAILY';

8. 5. Тригер affordability

sql
WITH m AS (
SELECT SUM(deposits - withdrawals) AS nd_30d
FROM payments. activity_rollup
WHERE user_id=:uid AND day >= CURRENT_DATE - INTERVAL '30 days'
)
INSERT INTO rg. affordability(user_id, status, sof_required, sow_required, requested_at)
SELECT:uid, 'REQUESTED', true, false, now()
FROM m WHERE m. nd_30d > 2000
ON CONFLICT (user_id) DO NOTHING;

9) KPI і дашборди

Share of Protected Play: частка активних гравців з лімітами ≥1.
Limit Hit Rate: частота спрацьовувань за типами (депозит/втрати/час).
Cooling-off/Self-exclusion Rate і повернення після паузи.
Affordability TAT (p50/p95), доля PASS/FAIL.
ND <0 Share і вплив лімітів на цей показник.
Chargeback bps/Refund rate до і після впровадження лімітів.
Abandonment в платежах через RG-блокування (guardrail-метрика).
Reality-check engagement: acknowledge rate, після-RC поведінка.

10) Алерти

Limit Hit Spike: зростання спрацьовувань> X% d/d по країні/каналу.
Affordability Backlog: TAT> SLA, черга> порогу.
Cooling-off Leak: спроби платежів у період паузи (P1).
Self-exclusion Mismatch: невідповідність із зовнішнім реєстром.
Policy Drift: платежі/ставки без перевірки лімітів.
ND Negative Surge у гравців без лімітів → запропонувати авто-ліміти.

11) Право і комплаєнс (конспект)

Прозорі тексти: прості пояснення ефектів лімітів, терміни вступу, скасування ослаблень.
Локальні норми: відмінності за періодами/видами лімітів і форматами reality-check; синхронізація з національними реєстрами self-exclusion.
Приватність: мінімізація даних affordability, зберігання доказів рішення (audit-trail).
Звітність: агрегати за лімітами/винятками в розрізі ліцензій/ринків.

12) Економіка і вплив

Зниження платіжних інцидентів (CB/Refund) і «червоних» тікетів.
Стабілізація LTV: менше «випалених» гаманців, більш здорові когортні метрики.
Операційні витрати: плануйте capacity на affordability/ручні кейси, автоматизуйте step-ups.

13) A/B і покрокове впровадження

Тестуйте copy і UX лімітів, інтервали reality-check, weaken_delay, stake_max.
Guardrails: AR/Abandonment, CB bps, ND <0 Share, скарги саппорта.
Дата-фриз з лагом на висновки/СВ; стратифікація по GEO/каналах.

14) Best practices (коротко)

1. Default-on інструменти RG, швидкий доступ з гаманця і чекауту.
2. Ослаблення лімітів - тільки із затримкою; посилення - відразу.
3. Reality-check за замовчуванням (60 хв) зі зрозумілою метрикою «чистий результат».
4. Risk-based step-ups (affordability/SoF) за порогами і сигналами, а не всім підряд.
5. Інтеграція з payout-політикою: ND, same-method, cooling-off на висновках.
6. Повна телеметрія: кожне рішення зберігати з версією політики і evidence.
7. Локалізація і а11у, прозорі тексти і чесні терміни.
8. Регулярні аудити відповідності ліцензіям та зовнішнім реєстрам.

15) Чек-лист впровадження

• Карта лімітів і періодів; weaken-delay; reality-check за замовчуванням.
• Псевдо-DSL політики, версіяція, аудит.
• Онлайн-гейти на депозит/гру/висновок; ND и same-method.
• Affordability тригери і процеси (SoF/SoW), SLA і алерти.
• UX: майстер лімітів, локалізація, a11y; осмислений copy.
• Дашборди KPI і guardrails; алерти і плейбуки інцидентів.
• Звірка з реєстрами self-exclusion; правові тексти локалями.
• Періодичні пост-аудити впливу на AR/CB/LTV і саппорт-навантаження.

Резюме

«Відповідальні платежі та ліміти» - це системний стек: політика і UX, онлайн-контроль в платежах/грі/висновках, risk-based ескалації (affordability/KYC/SoF), прив'язка до ND/same-method і повна телеметрія. Такий підхід одночасно знижує шкоду гравцям, стабілізує P&L і підтримує відповідність ліцензійним вимогам - без непотрібного тертя для сумлінної аудиторії.