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 при высоком обороте — принудительная KYС/SoF-проверка.
Ненормальная доля Refund/Chargeback в ND — аудит цепочки “депозит→игра→вывод”.

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 станет надежной опорой как для финансов, так и для ответственной монетизации.