Net Deposits：計算および制御

1）ネット預金とは何であり、なぜそれらが必要なのか

• 単位経済学（LTV、 ARPPU、 NGRとのNDの相関）、
• 責任あるゲーム（制限、自己管理、資金源）、
• リスクとコンプライアンス（AML/制裁、異常）、
• トランザクション（支払いの優先順位付けと乱用防止ボーナス）。

基本的な考え方

プレイヤーはX（預金）を寄付し、Y（引き出し）をもたらしました。プレイヤーの「実際に預金されたお金」としてエコシステムに残っているのは、リターン、チャージバック、キャンセル、その他の技術的操作のために調整されたNet Depositsです。

2）数式と会計境界

2.1.基本フォーミュラ（製品レベル）

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

• 預金-捕獲/決済のみ。その後のキャプチャなしの承認-カウントしないでください。
• 出金-私たちは支払われた（支払われた/決済された）のみを考慮します。拒否/キャンセルされたNDアプリケーションは減少しません。
• 返金された預金-預金は同じソース（同じ方法）に戻ります。
• チャージバックデビット/クレジット-紛争の純効果（ライトオフ/リターン）。
• 反転調整-技術的な修正（例えば、「erroneous」ウォレットからの復帰、重複の逆）。

2.2.会計機能の強化

ボーナスとフリーベット：預金には含まれていません。これは国内ローンです。しかし、乱用シナリオ（ボーナスの入金→即時キャッシュアウト）は、迅速な引き出しや不正防止の修正を通じてNDを削減する必要があります。
PSPコミッション：デフォルトでは、ND （ND-「プレーヤー中心」メトリック）から差し引かれません。手数料-P&L。
内部転送/クロスウォレット（スポーツ→カジノ）：NDは変更されません（これはバランス内の動きです）。
キャンセル中：キャンセルはNDを減少させません（結局、引き出しは行われませんでした）。
プロモーションキャッシュアウト/マニュアルクレジット：オペレータのキャッシュクレジットはNDを増加させません。
トークン/暗号：決済時に等価なフィアットに従って読み取ります（複数通貨を参照）。
部分的/分割支払い：NDは本当に決済される量によって成長しています。

2.3.期間の境界

• アクティビティベース（'settled_at'トランザクションによる）。財務報告のために推薦される。
• リクエストベース（'created_at'/'requested_at'）：迅速な製品分析に適していますが、調整には適していません。

3）複数通貨と為替レートの評価

すべての操作は、決済時の為替レートで通貨（例えばEUR）を報告することにマップされます。
Фиксируйте： 'amount_original'、 'currency_original'、 'fx_rate_at_settle'、 'amount_reporting'。
暗号の場合は、'setted_at'で選択したソースの加重平均価格（VWAP）を使用します。
コースを変更するときは、歴史的なNDを過大評価しないでください。イベント時に実際のFXを維持してください。

4） NDロールレベル

ND_userは特定のプレーヤーの純投資です。
ND_segment-国、チャネル、支払いプロバイダー、アフィリエイト。
ND_cohort-登録/最初の預金の日付までに。
ND_platform期間のプラットフォームの合計NDです。

5）ポリシーと除外

5.1.same-methodルール&ソースに戻る

deposit Aがmethod Mを通じて来た場合、deposit fundのリターンは、できれば純預金の金額までMを通じて行われます。これにより、AMLと物議を醸すクロスペイメントのリスクが軽減されます。

5.2.内部調整

任意の手動調整には、reason_code、監査証跡、およびプライマリアクティビティへの参照が必要です。
調整は、損失追跡/乱用をマスクすべきではありません。

5.3.ボーナスサイクル

「ボーナス駆動ND」（ボーナスを有効にした預金）をフラグでマークします。ボーナス関連の預金の有無にかかわらず、NDレポートを作成します。

6）イベントモデルとデータスキーム

6.1.主なイベント

'DEPOSIT_AUTHORIZED'、 'DEPOSIT_CAPTURE'、 'DEPOSIT_REFUNDED'

'RETHAL_REQUESTED'、 'RETHAL_PAID'、 'RETHAL_REQUESTED'、 'RETHAL_CANCELED'

'CHARGEBACK_DEBITED'、 'CHARGEBACK_CREDITED'

'ADJUSTMENT_APPLIED'（^^： REVERSAL、 TECH_FIX、 FRAUD_CORRECTION^。п.)

すべてのイベントはidempotent （'idempotency_key'、 'event_id'）です。'event_id'重複排除を介してDWHへの正確に一度の配信をサポートします。

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の合計は「タイプ」と「ステータス」による集計と見なされ、フィルタは「該当する場合にのみ、決済/有料/キャプチャされます」。

7）データ品質管理と和解

7.1.PSP/Acquirerとの和解

PSPレポートの毎日の和解（決済ファイル）あなたの「トランザクション」と。
'provider_ref'、金額、決済日、通貨、手数料（P&L）のマッチ。
ミスマッチ→Opsのチケット：「missing capture」、 「double refund」、 「late presentation」。

7.2.Antidubleおよびidempotency

コントロール：'（プロバイダ、provider_tx_id、タイプ、settle_date）'による一意性。
手動操作の監査ログ（'ADJUSTMENT_APPLIED'）を分離します。

7.3.ビジネスルールの整合性

選択した方法で入金履歴のない「PAID」を表示すると赤旗になります。
同じ金額の「DEPOSIT_CAPTED」→「DETHIRAL_PAID」-グレーフラグ（ボーナス乱用）。

8）レポートとダッシュボード

8.1.基本的なKPI

期間の'ND_total'；'ND_per_user'、'ND_median'；

国、方法、PSP、アフィリエイトによるNDの分解；

'ND_7/30/90'登録コホート；

キャッシュ・コンバージョン・ラグ：「DEPOSIT_CAPTED」から「DETHAL_PAID」までの中央値。

8.2.リスクセグメント

「ND≈0」と高い売上高を持つプレーヤーは、資金源の検証のための候補です。
迅速なターンアラウンド（入金→出金）<N時間-調査トリガー。

8.3.アナリティクスプレーン

プロダクト（スポーツ/カジノ/ライブ）：NDが最も「健康」であるところ。
支払方法：特定の方法での詐欺トラフィック中のND障害。
キャンペーン/ボーナス：NDアップリフトとポストエフェクトのキャンセル。

9）詐欺防止および責任ある再生ポリシー

入金限度額（毎日/毎週/毎月）-NDは別のコンプライアンスメトリックを報告します。
速度ルール：n deposits> X in Y minute+fast cache out=block/manual check。
制裁/PEP/SoF：しきい値を超えるND成長→必須資金源。
Mullocalization： geo/method/banking countryとKYC countryを比較します。
自己排除：排除後のNDは厳密に0でなければなりません。すべての試み-警告。

10）プロセスとSLO

NDダッシュボード計算のSLO： T+1、レポーティングエリアの09：00 ローカルTZまでの準備。

• PSP決済ファイルがありません、
• 重複すると、セグメントNDが正しくありません、
• FXの質量差。
• DRP：決定論的順序でイベントを再接続することでNDを再処理します。

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）アラートとトリガ（オペレーティングシステム）

スパイクNDメソッド： NDドロップ>30％ d/d-PSPインシデントとロックをチェックします。
セグメント別スパイクND： ND成長>50％ w/w-新しいaffがありそうです。-sourceまたはresetスキーム。
高いターンオーバーND≈0-強制KYC/SoFチェック。
NDにおける返金/チャージバックの異常なシェア-"depozit→igra→vyvod'チェーンの監査。

13）ベストプラクティス（短い）

1.決済日付でNDを読み取り、決済時にFXを修正します。
2.プレーヤーのお金から厳密に内部送金を分離します。
3.すべての手動編集-reason_codeと監査。
4.迅速なUターンとクロスメソッドのための不正防止ルール。
5.2つのレポート：T+1の営業と財務閉鎖（月/四半期）。
6.ロジックバージョニング：歴史的なストアフロントの移行を伴うND v1/v2。

14）頻繁な質問

Q：転覆した結果は数えられますか？
A：いいえ。NDを引き出すのは「DETWIRAL_PAID」だけです。

Q：許可されているがキャプチャされていないデポジットはどうすればよいですか？
A： NDに含まれていません。これらは実際の領収書ではありません。

Q：すでに締結した後にチャージバックを反映する方法は？
A： 'CHARGEBACK_DEBIT'は負のプレーヤーの貢献（基本的にはプラットフォームが失われます）を追加し、NDはデビットによって増加しますが、最終財務報告書にはチャージバックの損失/費用も表示する必要があります。

Q： PSPコミッションはNDから差し引かれる必要がありますか？
A：いいえ、NDはプレーヤー中心のメトリックです。手数料-P&L。

15）実装チェックリスト

• idempotencyと配信保証付きのイベントバス
• 'transactions_flat'は、統一されたタイプ/ステータスを持つショーケース
• settleのFX正規化、元のストレージ
• PSPステータスマッピングルール→ステータス
• PSPおよびデルタアラートとの毎日の和解
• NDダッシュボード（全体、方法別、セグメント別、コホート別）
• 責任ある再生ポリシーとNDベースのSoFトリガー
• ND v1数式ドキュメントと進化計画v2

概要

Net Depositsは、システム内のプレイヤーの「リアル」マネーの中心的な指標です。正しいNDには、厳格な認識規則（決済日）、正確な複数通貨、イベントのアイデンポテンス、PSPとの定期的な調整、および内蔵の不正防止トリガーが必要です。単一のステータスガイドとオペレーションのタイポロジーを形成し、NDは金融と責任ある収益化の両方を信頼できるサポートになります。