Net Deposits: розрахунок і контроль

1) Що таке Net Deposits і навіщо вони потрібні

• юніт-економіки (кореляція ND з LTV, ARPPU, NGR),
• відповідальної гри (ліміти, самоконтроль, джерело засобів),
• ризику та комплаєнсу (AML/санкції, аномалії),
• операцій (пріоритизація виплат і антиаб'юз бонусів).

Базова ідея

Гравець вніс X (deposits), вивів Y (withdrawals). Все, що залишилося в екосистемі як «реально внесені гроші» гравця, - це і є Net Deposits, скориговані на повернення, чарджбеки, скасування та інші технічні операції.

2) Формули і межі обліку

2. 1. Базова формула (рівень продукту)

ND = Deposits
− Withdrawals − (successful, paid)
− Refunded Deposits
+ Chargeback Debits
− Chargeback Credits
± Reversal Adjustments

• Deposits - тільки успішно зараховані (captured/settled). Авторизації без подальшого capture - не рахуємо.
• Withdrawals - враховуємо лише виплачені (paid/settled). Відхилені/скасовані заявки ND не зменшують.
• Refunded Deposits - повернення депозиту на те ж джерело (same-method).
• Chargeback Debits/Credits - чистий ефект диспутів (списання/повернення).
• Reversal Adjustments - техкорекції (наприклад, повернення з «помилкового» гаманця, сторно дубліката).

2. 2. Розширення обліку

Бонуси і Free Bets: не входять до Deposits; це внутрішні кредити. Однак abuse-сценарії (депозит заради бонусу → миттєвий кеш-аут) повинні знижувати ND через швидкі Withdrawals і/або через antifraud-корекції.
Комісії PSP: за замовчуванням не віднімаються з ND (ND - «гравсько-центрична» метрика). Комісії - в P & L.
Internal Transfer/Cross-Wallet (спорт → казино): ND не змінюється (це рух всередині балансу).
Cancel Withdrawal: скасування не зменшує ND (адже висновок не відбувся).
Promotional Cashout/Manual Credit: грошові кредити оператора не збільшують ND.
Токени/крипто: вважати за фіатним еквівалентом на момент settle (див. мультивалютність).
Partial/Split Payments: ND зростає на суму, яка реально settled.

2. 3. Межі періоду

• Activity-based (по'settled _ at'транзакції). Рекомендується для фінансової звітності.
• Request-based (по `created_at`/`requested_at`): годиться для швидкої продуктової аналітики, але не для звірки.

3) Мультивалютність та оцінка курсів

Всі операції маппятся в reporting currency (наприклад, EUR) за курсом на момент settle.
Фіксуйте: `amount_original`, `currency_original`, `fx_rate_at_settle`, `amount_reporting`.
Для крипто: використовуйте середньозважену ціну (VWAP) на вибраному джерелі на'settled _ at'.
Не переоцінювати історичні ND при зміні курсів: зберігайте фактичний FX на момент події.

4) Рольові рівні ND

ND_user - чисті вкладення конкретного гравця.
ND_segment - по країнах, каналах, провайдерам оплати, афіліатам.
ND_cohort - за датами реєстрації/першого депозиту.
ND_platform - загальний ND платформи за період.

5) Політики та винятки

5. 1. Правило same-method & повернення на джерело

Якщо депозит A прийшов через метод M, повернення депозитних коштів бажано робити через M до суми нетто-внесення. Це знижує ризики AML і спірних крос-виплат.

5. 2. Внутрішні коригування

Будь-яке ручне коригування повинно мати reason_code, audit trail і посилання на первинну операцію.
Коригування не повинні маскувати loss-chasing/abuse.

5. 3. Бонусні цикли

Позначайте «bonus-driven ND» (депозит, що активував бонус) прапором. Будуйте звіти ND з/без бонус-пов'язаних депозитів.

6) Подієва модель і схема даних

6. 1. Ключові події

`DEPOSIT_AUTHORIZED`, `DEPOSIT_CAPTURED`, `DEPOSIT_REFUNDED`

`WITHDRAWAL_REQUESTED`, `WITHDRAWAL_PAID`, `WITHDRAWAL_REJECTED`, `WITHDRAWAL_CANCELED`

`CHARGEBACK_DEBITED`, `CHARGEBACK_CREDITED`

`ADJUSTMENT_APPLIED` (тип: REVERSAL, TECH_FIX, FRAUD_CORRECTION и т. п.)

Всі події - ідемпотентні ('idempotency _ key','event _ id'). Підтримуйте exactly-once доставки в DWH через дедуплікацію по'event _ id'.

6. 2. Міні-схема (спрощено)

payments. transactions (
id, user_id, provider, method, type, status,
amount_original, currency_original,
amount_reporting, reporting_currency, fx_rate_at_settle,
requested_at, settled_at, related_tx_id, reason_code, meta
)

types: DEPOSIT    WITHDRAWAL    REFUND    CHARGEBACK_DEBIT    CHARGEBACK_CREDIT    ADJUSTMENT status: PENDING    AUTHORIZED    CAPTURED    PAID    REJECTED    CANCELED    REFUNDED    SETTLED

Підсумки по ND вважаються агрегаціями по'type'і'status'з фільтрами «тільки settled/paid/captured, де застосовується».

7) Контроль якості даних і звірка

7. 1. Звірка з PSP/Acquirer

Щоденна звірка PSP-звітів (settlement files) з вашою'transactions'.
Матчі по'provider _ ref', сумам, датам settle, валютам і fee (для P&L).
Розбіжності → тікети в Ops: “missing capture”, “double refund”, “late presentment”.

7. 2. Антидубль та ідемпотентність

Контроль: унікальність по'( provider, provider_tx_id, type, settle_date)'.
Окремий аудит лог за ручними операціями ('ADJUSTMENT _ APPLIED').

7. 3. Цілісність бізнес-правил

Висновок «PAID» без депозитної історії в обраному методі - червоний прапор.
Близькі за часом'DEPOSIT _ CAPTURED'→'WITHDRAWAL _ PAID'на ту ж суму - сірий прапор (bonus-abuse).

8) Звітність і дашборди

8. 1. Базові KPI

'ND _ total'за період;'ND _ per _ user','ND _ median';

Розкладання ND по країнах, методам, PSP, афіліатам;

'ND _ 7/30/90'за когортами реєстрації;

Cash Conversion Lag: медіана від'DEPOSIT _ CAPTURED'до'WITHDRAWAL _ PAID'.

8. 2. Сегменти ризику

Гравці з «ND≈0» і високим оборотом - кандидати на перевірку джерела коштів.
Швидкий розворот (deposit→withdrawal) <N годин - тригер розслідування.

8. 3. Площини аналітики

Продукт (спорт/казино/live): де ND найбільш «здоровий».
Методи оплати: провали ND при фрод-трафіку на конкретному методі.
Кампанії/бонуси: ND-uplift і пост-ефект відмін.

9) Політики антифроду і відповідальної гри

Ліміти депозитів (daily/weekly/monthly) - у ND-звітах окремою метрикою дотримання.
Velocity-правила: n депозитів> X за Y хвилин + швидкий кеш-аут = блок/мануальна перевірка.
Санкції/PEP/SoF: зростання ND вище порогу → обов'язковий Source of Funds.
Муллокалізація: порівнюйте гео/метод/банківську країну з KYC-країною.
Self-exclusion: ND після виключення має бути строго 0; будь-які спроби - алерт.

10) Процеси і SLO

SLO розрахунку ND-дашборду: T + 1, готовність до 09:00 локального TZ звітної зони.

• пропущені settlement-файли PSP,
• дублікати призводять до невірного ND сегмента,
• масові розбіжності FX.
• DRP: репроцесинг ND через re-ingest подій за період з детермінованим порядком.

11) Приклади SQL (шаблони)

11. 1. Розрахунок ND по користувачеві і дню

sql
WITH base AS (
SELECT user_id,
DATE(settled_at) AS d,
SUM(CASE WHEN type='DEPOSIT'     AND status IN ('CAPTURED','SETTLED') THEN amount_reporting ELSE 0 END) AS dep,
SUM(CASE WHEN type='WITHDRAWAL'   AND status='PAID'           THEN amount_reporting ELSE 0 END) AS wd,
SUM(CASE WHEN type='REFUND'     AND status='SETTLED'         THEN amount_reporting ELSE 0 END) AS ref_dep,
SUM(CASE WHEN type='CHARGEBACK_DEBIT'  AND status='SETTLED'        THEN amount_reporting ELSE 0 END) AS cb_deb,
SUM(CASE WHEN type='CHARGEBACK_CREDIT' AND status='SETTLED'        THEN amount_reporting ELSE 0 END) AS cb_cr
FROM dw. transactions_flat
WHERE settled_at >=:from AND settled_at <:to
GROUP BY 1,2
)
SELECT user_id, d,
dep - wd - ref_dep + cb_deb - cb_cr AS nd
FROM base;

11. 2. Прапор швидких розворотів (аб'юз)

sql
SELECT t_dep. user_id, t_dep. id AS dep_id, t_wd. id AS wd_id,
EXTRACT(EPOCH FROM (t_wd. settled_at - t_dep. settled_at))/3600 AS hours_between,
t_dep. amount_reporting, t_wd. amount_reporting
FROM dw. transactions_flat t_dep
JOIN dw. transactions_flat t_wd
ON t_dep. user_id = t_wd. user_id
AND t_wd. type='WITHDRAWAL' AND t_wd. status='PAID'
AND t_wd. amount_reporting BETWEEN t_dep. amount_reporting0. 9 AND t_dep. amount_reporting1. 1
WHERE t_dep. type='DEPOSIT' AND t_dep. status IN ('CAPTURED','SETTLED')
AND t_wd. settled_at - t_dep. settled_at <= INTERVAL '24 hours';

11. 3. Сегментація за методами/PSP

sql
SELECT method, provider,
SUM(CASE WHEN type='DEPOSIT'  AND status IN ('CAPTURED','SETTLED') THEN amount_reporting ELSE 0 END) AS dep,
SUM(CASE WHEN type='WITHDRAWAL' AND status='PAID'          THEN amount_reporting ELSE 0 END) AS wd,
SUM(CASE WHEN type='REFUND'   AND status='SETTLED'         THEN amount_reporting ELSE 0 END) AS ref_dep,
SUM(CASE WHEN type='CHARGEBACK_DEBIT' AND status='SETTLED'     THEN amount_reporting ELSE 0 END) AS cb_deb,
SUM(CASE WHEN type='CHARGEBACK_CREDIT' AND status='SETTLED'     THEN amount_reporting ELSE 0 END) AS cb_cr,
SUM(CASE WHEN type='DEPOSIT'  AND status IN ('CAPTURED','SETTLED') THEN amount_reporting ELSE 0 END)
- SUM(CASE WHEN type='WITHDRAWAL' AND status='PAID'          THEN amount_reporting ELSE 0 END)
- SUM(CASE WHEN type='REFUND'   AND status='SETTLED'         THEN amount_reporting ELSE 0 END)
+ SUM(CASE WHEN type='CHARGEBACK_DEBIT' AND status='SETTLED'     THEN amount_reporting ELSE 0 END)
- SUM(CASE WHEN type='CHARGEBACK_CREDIT' AND status='SETTLED'     THEN amount_reporting ELSE 0 END) AS nd
FROM dw. transactions_flat
WHERE settled_at BETWEEN:from AND:to
GROUP BY 1,2
ORDER BY nd DESC;

12) Алерти і тригери (операційка)

Spike ND↓ на методі: падіння ND> 30% d/d - перевірити PSP-інциденти і блокування.
Spike ND↑ за сегментом: зростання ND> 50% w/w - ймовірний новий афф. Джерело або схема обнала.
ND≈0 при високому обороті - примусова KYC/SoF-перевірка.
Ненормальна частка Refund/Chargeback в ND - аудит ланцюжка «depozit→igra→vyvod».

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

1. Вважати ND за settle-датами і фіксувати FX на момент settle.
2. Жорстко відокремлювати internal transfer від грошей гравця.
3. Всі ручні правки - з reason_code і аудитом.
4. Антифрод-правила на швидкі розвороти і крос-методи.
5. Два звіти: операційний T + 1 і фінансовий закриваючий (місяць/квартал).
6. Версіонування логіки: ND v1/v2 з міграцією історичних вітрин.

14) Часті питання

Q: Чи враховувати скасовані висновки?
A: Ні, ні. Тільки'WITHDRAWAL _ PAID'зменшує ND.

Q: Що робити з депозитом, який був авторизований, але не захоплений?
A: Не включати в ND. Це не реальні надходження.

Q: Як відображати chargeback після вже зробленого висновку?
A: 'CHARGEBACK _ DEBIT'додасть негативний внесок гравця (по суті, платформа втрачає), ND збільшиться на дебет, але підсумковий фінансовий звіт також повинен показати збиток/витрату по чарджбекам.

Q: Чи потрібно віднімати PSP-комісії з ND?
A: Ні, ND - гравсько-центрична метрика. Комісії - в P & L.

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

• Подієва шина з ідемпотентністю та гарантією доставки
• Вітрина'transactions _ flat'з уніфікованими типами/статусами
• FX-нормалізація на settle, зберігання оригіналів
• Правила mapping PSP-статусів → ваші статуси
• Щоденна звірка з PSP і алерти на дельти
• Дашборди ND (загальний, за методами, за сегментами, за когортами)
• Політики відповідальної гри і SoF-тригери на базі ND
• Документація формули ND v1 і план еволюції v2

Резюме

Net Deposits - центральна метрика «реальних» грошей гравця в системі. Коректний ND вимагає суворих правил визнання (settle-дати), акуратної мультивалютності, подієвої ідемпотентності, регулярної звірки з PSP і вбудованих антифрод-тригерів. Сформуйте єдиний довідник статусів і типологію операцій - і ND стане надійною опорою як для фінансів, так і для відповідальної монетизації.