財政部：流動性和準備金

TL;DR

iGaming的財政部是一個管理流動性「口袋」網絡（銀行，PSP，錢包，加密種姓，商戶帳戶），每個輸入/輸出具有不同的SLA。目標是在最低成本下實現零現金缺口：準確的流量預測，交易對手和貨幣的限制，儲備政策（操作緩沖區+監管安全性+壓力儲備），預付和掃蕩規則紀律，時間到付款和時間到基金的SLO。

1）流動性卡： 水平、口袋、流量

1.1流動性水平（按可用性）

L0 （T0）-即時流動性：商戶賬戶、即時A2A/RTP、錢包、存錢儲備、現金緩沖區以支付T0。
L1 （T+1…… T+3）-短線流動性：PSP/收購人結算賬戶，日內限額銀行經常賬戶。
L2（T+5…… T+10）-中層流動性：存款/儲蓄賬戶，掃入國庫工具（T-bills，MMF），快速越位的「停車」賭註。
L3 （T+10+）-戰略流動性/資本：長期存款、債券、保留資本。

1.2流動性口袋（示例）

Bank_OPS（經營銀行）：進出/退出，工資，稅收。
PSP_MERCHANT：方法商戶賬戶（Card、A2A、Wallet）。
PSP_SETTLEMENT：結算/累積賬戶（T+N）。
CRYPTO_CUSTODY：股票/種姓、股票和基本資產。
PAYOUT_POOLS：瞬時付款的單獨池。
SAFEGUARD_ACCOUNTS：根據監管/許可要求分離賬戶。

1.3主流

`Deposits → PSP_MERCHANT → Settlement → Bank_OPS`

`Bank_OPS → Payout_Pools/PSP → Withdrawals`

`On/Off-ramp ↔ Crypto_Custody`

「Sweeps： L0↔L1↔L2」在時間表和觸發器上。

2）流動性和準備金政策

2.1個目標

關鍵支付軌道上的零現金缺口。
流動性最低擁有成本（費用、外匯、收入損失）。
法規遵從性：safeguarding,客戶工具隔離（如果適用）。
透明度：SLO的每日對賬和行車記錄。

2.2類儲備

1.Operation Reserve （OpRes）-覆蓋支付峰值和設置變異性（例如,p99日凈輸出+緩沖區20-30%）。
2.監管儲備（RegRes）是許可證要求的金額（segregated，safeguarding，ring-fencing）。
3.壓力儲備（StressRes）-罕見休克的覆蓋範圍：「雙重」峰值輸出，關鍵PSP的T+N延遲，FX休克。
4.技術儲備（TechRes）-用於操縱器/事件（現場/交易所/銀行凍結）。

2.3按口袋分配的目標余額公式

Target_Balance = OpRes(p99 horizon H) + RegRes + StressRes - Incoming_Settlement(T_window)

H地平線和窗口T_window取決於導軌（例如RTP H=1d，Card H=3d）。

3）現金流預測

3.1個輸入行

Deposits by method/provider （p7/p30季節性,周日,促銷）。
Withdrawals＆Payouts（速度和存款份額，VIP/頭獎）。
定居權計劃（PSP/收購商的 T+N）。
FX日歷（重新評估，主要轉換）。
運營付款（稅收，傭金，薪水）。

3.2型號（最低）

本地加權或SARIMA/Prophet用於倉庫/端子。
應用系數：「現金率」，「Jackpot Probability」，「Promo Lift」。
口袋裏的凈位置：「Inflow_psp_settlement − Outflow_payouts ± Sweeps」。

3.3個預測質量指標

MAPE/WAPE每日凈值。
覆蓋：實際峰值≤計劃OpRes的天數比例。
Stockout Incidents： L0離開時的次數<最低閾值。

4）預備、交換和充值規則

4.1預留（預付鐵路）

軌道和某些APM的即時付款需要平衡。
規則：保持滾動閾值（例如最後一周的p95日付款）+20％的緩沖區。
自動輔助觸發器："Balance <LowWatermark" → "TopUp to Target_Balance'。

4.2 Sweeps（掃描翻譯）

每日：PSP_MERCHANT → Bank_OPS設置窗口後。
Intradei：偏離目標走廊的L0↔L1。
向L2：在MMF/T-Bills/stables中過量殘留的夜間掃蕩（返回策略為L0 ≤ T+1）。

4.3支出優先級（waterfall）

1.Payout_Pools （T0義務）

2.固定截止日期國庫付款（稅收/工資）

3.轉換/重組FX

4.投資L2/L3

5）貨幣、外匯和利率環境

FX曝光：進出貨幣余額；自然對沖（支持以相同貨幣付款）。
轉換策略：TWAP/POV-algo適用於大筆金額,slippage bps限制,idempotent exec-id。
L2的百分比收益率：MMF/短 T-bills；交易對手限制和最低流動性（T+0/T+1）。
SLO FX轉換：從解決方案到執行的時間（p95 ≤ X分鐘）,報價日誌。

6）對手風險和限制

交易對手的限制：銀行，PSP，加密種姓，交易所/OTS。
評級矩陣：資本/許可證/事件/可用性/儲備證明（用於加密）。
多樣化：每個關鍵軌道至少2-3個提供商，殘留物按集群分布。
Custody policy： multicig/HSM,輸出限制,地址列表,每日對賬。

7）監管和合規方面

Safeguarding/segregation：單獨的客戶基金賬戶（在需要時）,跟蹤資產負債表,禁止混合。
報告：向監管機構/審計機構提交關於余額和準備金的每日報告。
KYC/AML： on/off-ramp對手、制裁篩選、SoF/SoW進行重大轉移。
DSAR/retention：保留支付跟蹤和轉移日誌。

8）度量，SLO和Alertes

8.1 KPI

時間到工資（TtP）p95的方法。
時間到基金（TtF）p95用於池充值。
Stockout Rate L0（即時流動性不足事件）。
Cash Utilization=L0/ Target_Balance付款。
平均現金%=（資產負債表− Target_Balance）/資產負債表。
Counterparty Concentration=max（按提供商劃分）。

FX Slippage bps, FX Cost/GGR.

Safeguard Coverage=min（隔離帳戶余額/所需金額）。

8.2 Alerta

「Balance <LowWatermark」 → P1（自動補充）。
「Stockout Incident」 → P0（即時支付單元/包括替代品）。
「Counterparty Concentration>限制」→ P2（重組）。

`Safeguard Coverage < 100%` → P0.

'TtF p95> SLO' → P1（銀行/PSP發生的事件）。

9）數據模型（庫存「層」）

json
{
"as_of": "2025-11-03T12:00:00Z",
"pocket_id": "PSP_MERCHANT_CARD_A",
"currency": "EUR",
"balance": 425000. 00,
"target_balance": 380000. 00,
"low_watermark": 300000. 00,
"inflows_t0": 52000. 00,
"outflows_t0": 61000. 00,
"expected_settlement_t1": 210000. 00,
"safeguard_required": 150000. 00,
"safeguard_balance": 160000. 00,
"counterparty": "Acquirer_A",
"limits": {
"counterparty_limit": 1200000. 00,
"fx_slippage_bps_limit": 5
},
"alerts": ["BALANCE_BELOW_TARGET"],
"notes": "Expect promo cash-out spike tonight"
}

date, pocket_id, counterparty, currency,
balance, target_balance, low_watermark,
inflows_t0, outflows_t0, expected_settlement_t1,
safeguard_required, safeguard_balance,
payout_slo_p95_sec, fund_slo_p95_sec

10） SQL切片

10.1殘留物移動和進入走廊

sql
SELECT date,
pocket_id,
currency,
balance,
target_balance,
low_watermark,
CASE WHEN balance < low_watermark THEN 1 ELSE 0 END AS stockout_flag,
GREATEST(0, balance - target_balance) AS idle_cash
FROM treasury_balances_daily
ORDER BY date DESC, pocket_id;

10.2按對應方分列的集中

sql
SELECT date,
counterparty,
SUM(balance) AS bal,
SUM(SUM(balance)) OVER (PARTITION BY date) AS bal_total,
(SUM(balance) / NULLIF(SUM(SUM(balance)) OVER (PARTITION BY date),0)) AS share
FROM treasury_balances_daily
GROUP BY 1,2
ORDER BY date DESC, share DESC;

10.3 safeguarding覆蓋

sql
SELECT date, pocket_id, currency,
safeguard_balance, safeguard_required,
safeguard_balance / NULLIF(safeguard_required,0) AS coverage_ratio
FROM treasury_balances_daily
WHERE safeguard_required > 0;

11）Dashbord（最小小部件）

1.口袋裏的熱圖：'balance vs target vs low_watermark'。
2.票房漏鬥：「侵入/溢出/定居」。
3.方法/提供商的TtP/TtF p50/p95。
4.Counterparty concentration和Alertes。
5.Safeguard coverage： 100% lini,違規行為。
6.FX面板：slippage/成本,大型轉換。

12）花花公子

尖峰（現金流出）

行動：增加Target_Balance Payout_Pools，加快PSP→Bank_OPS掃蕩，暫時降低高風險的輸出限制，包括第二個即時付款提供商。

PSP的延遲設置

行動：激活StressRes，打開信用額度/透支，將付款暫時重新分配給備用軌道，升級為PSP。

銀行/交易所/種姓凍結

行動：kill-switch轉移，將余額轉移到替代交易對手，啟動DR計劃，召回密鑰/訪問，與監管機構溝通。

FX沖擊/超額貨幣需求

行動：包括TWAP加速的自然對沖（以相同貨幣付款），重新分配「本國」貨幣的股票/獎金。

safeguard塗層短缺

行動：立即將資金轉入隔離賬戶，阻止非必要付款，向監管機構報告並確認。

13）測試案例（UAT/Prod準備）

1.Stockout演練：模擬p99支付高峰→ L0池仍然≥ low_watermark。
2.PSP定點延遲：+2天到T+N → StressRes覆蓋，TtP不超越SLO。
3.FX TWAP等效性：重播webhook報價→ 1執行。
4.Safeguard breach：自動交換和阻止非關鍵支付。
5.Counterparty cap：超過提供商→ alert+auto rebalance的限制。
6.Intraday sweep：資產負債表>Target_Balance+δ →在L2中刷卡，在家門口返回。

14）常見錯誤以及如何避免錯誤

每個關鍵軌道的一個提供商→沒有捕獲器。保持至少兩個。
OpRes中缺少P級 →眼部儲備和頻繁的停擺。應用p95/p99。
未標記的safeguard帳戶→資金混合。輸入嚴格的隔離和報告。
忽略設置日歷→不正確的目標余額。自動化PSP日程安排。
L0/L1中的簡單緩存→損失收益的高成本。在L2中配置掃描。
沒有單一的「口袋登記冊」→殘余混亂。輸入Pocket Registry。

15）口袋登記冊（口袋登記冊，API草圖）

json
{
"pocket_id": "PAYOUT_POOL_EUR",
"type": "L0",
"counterparty": "Bank_X",
"currency": "EUR",
"segregated": false,
"prefund_required": true,
"slo": { "ttp_p95_sec": 60, "ttf_p95_min": 30 },
"limits": {
"low_watermark": 200000,
"target_balance": 350000,
"counterparty_limit": 1000000
},
"sweep_policy": {
"to_l2_when_idle_cash_over": 100000,
"intraday": true
}
}

總結

可持續財政部是一個系統而不是一組帳戶：分層流動性水平（L0-L3），管理儲備（OpRes/RegRes/StressRes），嚴格的限制和SLO，流量預測以及自動預留/掃蕩機制。所以你給企業最低TtP，避免現金缺口，降低資本成本，同時滿足監管機構和審計的要求。