設置循環和切斷

1）概念基礎

Settlement（設置）是PSP/Acquirer和商人（運營商）之間的計算，其中成功捕獲的交易中的錢轉入商人帳戶。
切斷是進入特定計算周期（通常是提供商時間段的固定時間）的操作的每日「切斷」。
T+N是資金間隔延遲的典型表示法：T是截止日期，N是實際入學前的工作日數。

• 卡（Visa/Mastercard）：通常是T+2/T+3銀行日，世界標準時間23：00（大約）。
• A2A/開放銀行：從T+0到T+1。
• SEPA Credit Transfer: T+1/T+2 (Instant — T+0).
• ACH (US): T+2/T+3;Same Day ACH — T+0/T+1.
• RTP （US）： T +0，但報告可能會截斷。
• 加密：實際上是通過網絡的T+0，但是PSP可以應用自己的調用窗口（T+0/1）。

2）切斷是如何工作的，什麼擊中它

1.提供商捕獲收集窗口（例如UTC 00：00-23：00）。
2.此窗口中的所有settled/captured事務都屬於數據包（batch）。
3.匯總到軟件包的收益，charjbacks，校正以計算gross和net funding。
4.在切斷前進時，會形成定位文件，並在入伍前開始T+N計時器。

重要的是：沒有捕獲的授權不會進入軟件包。取消的結論也沒有。

3）結算類型： gross vs net，儲備金和傭金

Gross定位-總捕獲量（減去單獨的傭金註銷）列出。
Net settlement-提供商持有fees, chargebacks, refunds, rolling reserve,並列出net amount。
滾動儲備-將營業額的百分比保持在N天（例如10％的180天）以涵蓋風險。
無關緊要-如果每天「凈額」進入負數，則赤字將被轉移並按以下周期償還。

建議：存儲兩個平面的解密：操作性gross（通過事務）和funding net（通過提供程序文件）。

4）時區，本地周末和DST

切斷由提供商的時間表定義，該時間表可能與您的時間表不同。
考慮DST（夏令時）-切片可以相對於本地時間移動± 1小時。
接收銀行轄區的假期/周末影響T+N中的N（例如，T+2銀行日變成假期周圍的T+4）。
實踐：在UTC中規範所有技術時間，並行存儲「provider_tz_cutoff_at」和「local_tz_posted_at」。

5）設置日歷（funding calendar）和SLA

• 每種方法/PSP的切斷時間和tz，
• 標準T+N和例外（假期），
• 預期數額（預測）
• 收件的SLA：例如，「不遲於T+2日歐洲時間12：00 Kyiv。」

任何SLA偏差都→ Ops/Finance中的alert和tiket。

6）與Net Deposits和結論的關系

ND（凈輸入）通過定位的事務來計算（請參閱相關文章）。
結論（withdrawals）不參與PSP的存款籌款，但會影響商人的票房。
流動性規劃：按設置輸入減去付款/稅收/運營費用外流。

7）對賬（reconciliation）和提供商的工件

• 'batch_id/ settlement_id'，在tz提供商的截止日期，
• суммы по типам: `captured_deposits`, `refunds`, `chargeback_debits`, `chargeback_credits`, `fees`, `reserve_delta`, `net_funding`,
• 方法/商人帳戶解密（「MID」，「descriptor」，「MCC」），
• 事務參考（「provider_tx_id」，「rrn」，「arn」-如果地圖），
• 文件：CSV/XML/JSON+人文聲明（PDF/HTML）。

1.從事務到文件（我們認為一切都進入了文件?）

2.從文件到事務（文件中的任何內容都在我們的展示櫃中？狀態是否匹配？）

8）付款軌道的細節（一般而言）

地圖：頻繁的情景延遲發布；可能的後期「chargeback」（案件最多120-540天）；interchange&scheme fees出現在文件中,在ND中不減法。
SEPA/ACH：batchi取決於銀行窗口；撤銷/退貨有自己的代碼；Same Day變體-單獨的剪切。
開放銀行/A2A：T+0/1，但文件可以事後處理；比賽需要嚴格的RPP/Unique ID。
RTP/Instant：錢來得快，但報告文件按計劃。
加密：onchein設置是即時的，但是提供者做「payout windows」；存儲「fx_at_settle」。

9）會計，結算和報告（FI/會計）

9.1.Ackrual vs緩存方法

對於管理報告，通常會使用accrual：在「settled_at」時承認收入/移動。
對於財政部/DDS，一種緩存方法：承認「funded_at」的到來。

9.2.典型布線（簡化）

• Dt：與PSP結算中的現金（AR：PSP）
• CT：對玩家的承諾（錢包/玩家平衡）

• Dt：銀行（商人出納處）
• CT：與PSP結算中的現金
• Dt：支出（PSP fees）, Dt/Ct：儲備（如果更改）

存儲用於跟蹤的"transaction_id → batch_id → funding_id'捆綁包。

10）風險管理和Alerta

Missed file： X： YY-P1之前沒有設置文件。

Funding delay： T+N到期,沒有錢-P1.

Delta thresholds： 「our_gross」與「file_gross」> 0的差異。5%是P2； 'fees'範圍之外是P2.

Negative carry-over：一系列負面的凈數據包-調查。
假期影響：自動預測,包括日歷；如果事實<80%的預測是滴答作響。

11）數據模型（簡化）

finance. payment_transactions (
id, user_id, method, provider, mid, mcc,
type, status, amount_original, currency_original,
amount_reporting, reporting_currency, fx_rate_at_settle,
authorized_at, captured_at, settled_at,
provider_tx_id, arn, rrn, meta
)

finance. settlement_batches (
batch_id, provider, mid, method,
provider_cutoff_at, provider_tz,
period_start_at, period_end_at,
gross_captured, refunds, cb_debits, cb_credits,
fees, reserve_delta, net_funding_expected,
file_name, file_hash, file_type, meta
)

finance. funding_receipts (
funding_id, provider, bank_account,
received_at, value_date,
currency, amount_received,
batch_id, statement_ref, meta
)

-- Binding showcase:
finance. recon_links (
id, transaction_id, batch_id, funding_id, link_type, created_at
)

12） SQL模板示例

12.1.通過切斷註冊「切片」

sql
INSERT INTO finance. settlement_batches (
batch_id, provider, mid, method,
provider_cutoff_at, provider_tz,
period_start_at, period_end_at,
gross_captured, refunds, cb_debits, cb_credits,
fees, reserve_delta, net_funding_expected,
file_name, file_hash, file_type, meta
)
VALUES (:batch_id,:provider,:mid,:method,
:cutoff_at,:tz,
:start_at,:end_at,
:gross,:refunds,:cb_deb,:cb_cr,
:fees,:reserve_delta,:net_expected,
:file_name,:file_hash,:file_type,:meta::jsonb);

12.2.從事務到文件的對賬"

sql
WITH tx AS (
SELECT provider, mid, method,
SUM(CASE WHEN type='DEPOSIT' AND status IN ('CAPTURED','SETTLED') THEN amount_reporting ELSE 0 END) AS gross,
SUM(CASE WHEN type='REFUND' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS refunds,
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 finance. payment_transactions
WHERE settled_at >=:start_at AND settled_at <:end_at
GROUP BY 1,2,3
)
SELECT b. batch_id, b. provider, b. mid, b. method,
tx. gross AS our_gross, b. gross_captured AS file_gross,
tx. refunds AS our_refunds, b. refunds AS file_refunds,
tx. cb_deb AS our_cb_deb, b. cb_debits AS file_cb_deb,
tx. cb_cr AS our_cb_cr, b. cb_credits AS file_cb_cr
FROM finance. settlement_batches b
LEFT JOIN tx
ON tx. provider=b. provider AND tx. mid=b. mid AND tx. method=b. method
WHERE b. provider_cutoff_at BETWEEN:cutoff_from AND:cutoff_to;

12.3.收入預測（現金流T+N）

sql
SELECT provider, mid, method,
DATE(provider_cutoff_at) AS t_date,
net_funding_expected,
CASE
WHEN EXTRACT (DOW FROM provider_cutoff_at)::int IN (5,6) THEN provider_cutoff_at + INTERVAL '3day' -- conditional example
ELSE provider_cutoff_at + INTERVAL '2 day'
END AS expected_funding_at
FROM finance. settlement_batches
WHERE provider_cutoff_at BETWEEN:from AND:to;

13）流程和SLO

SLO 1： settlement文件導入-T +0,直到08：00 Europe/Kyiv。

SLO 2： 主要對賬-直到09：00,差異差異>0.5%.

SLO 3：預測現金流更新-直到上午10點。
SLO 4：當天結束-所有在DWH舉行的比賽。

14） Edge-cases以及如何處理它們

Late presentment：交易進入下一批次-存儲"源事實"（"presented_in_batch_id'）。
部分捕獲：每個授權多個捕獲-正確聚合到擊球中。
Multi-MID：一個提供商，不同的地理/品牌的MID-不要混為一談。
重新設計：在文件斜邊時,「batch_revision」和完整的筆對。
FX賽馬：課程-在「settled_at」上；以其他貨幣進行融資-建立「fx_at_funding」和delta。

15） Dashbords和KPI

Funding ETA：預期的到達日期/時間與事實。
Hit-rate SLA：按時到達的文件比例。
提供商，方法，MID的Delta gross/net。

Fees % of volume, Reserve balance, Negative carry-over streak.

假日沖擊：假期周的預測vs事實。

16）最佳實踐（簡稱）

1.在UTC中正常化時間,但保留provider_tz切斷。
2.將操作雜交和籌款網絡分開；不要混淆ND和funding。
3.在銀行中引入預先安排的假期計劃日歷。
4.在SLA/Delta上自動導入和核對settlement文件+alerta。
5.實現批次轉換（「batch_revision」）和確定性重復。
6.輸入一個單一的真相來源：「transaction ↔ batch ↔ funding」鏈接。
7.保留ARN/RRN和卡的收購字段-對於分配至關重要。
8.根據周末/假期、儲備金和傭金預測現金流量。

17）實施支票

數據和圖表

[] Таблицы `payment_transactions`, `settlement_batches`, `funding_receipts`, `recon_links`.

• 時區字段：UTC+provider_tz。

[] Поля FX: `fx_rate_at_settle`, `fx_at_funding`.

導入和驗證

• CSV/XML/JSON+文件哈希解析器。
• 金額/貨幣/日期的核證；match по `provider_tx_id/ARN`.
• Hendlers 「late presentment」，「partial capture」，「reversal」。

操作和Alertes

• SLA截斷顯示器,missed files, funding delays。
• Delta閾值差值（gross, fees, net）。
• Holiday impact and negative carry-over報告。

18) FAQ

Q： 為什麼T+2變成T+4?

答： 在代理銀行或接收銀行有周末/假期；см. funding calendar.

Q： net文件中的數量少於我們的net計算。看什麼？
答：檢查功能，reserve_delta，後期再融資/充電包，以及課程的正確性。

Q： 如何考慮加密?

A：在「settled_at」上的法定等效項；funding可以在USDT/fiat中出現-存儲單獨的「fx_at_funding」。

Q： 是否可以為所有提供商提供一個共同的切斷?

答：不，每個PSP都有自己的tz/小時。在他們的切片上做一個聚合店面。

總結

• 準確地檢查提供商，
• 預測流動性和支付範圍，
• 遵守SLA並減少運營風險，
• 講與財務和合規相同的語言。

通過實施單一的計劃日歷，嚴格的數據模型和自動對賬，您可以使現金流可預測和可管理。