SWIFT和國際轉移

1） SWIFT在iGaming中的時間和原因

• 沒有本地軌道（SEPA/FPS/ACH）或需要向其他司法管轄區支付B2B；
• 需要向合作夥伴/附屬機構付款，納稅，大額流動性回購（離岸外包→菲亞特）；
• 需要本地電路上不存在的貨幣。
• 優點：全局覆蓋,高可預測性gpi。缺點：成本（fee+FX），時限（T+0-T+3），合規摩擦。

2）基本力學： 代理銀行和路由

受益人的BIC →接受銀行。如果沒有直接關系，則通過通訊員（nostro/vostro）付款。

• Serial (MT103/ISO pacs.008依次進行bank→korr→bank）。
• Cover（通過COV/pacs MT202共享付款和覆蓋範圍。009).
• 路線數據：受益人銀行的BIC，IBAN/帳戶，地址/名稱，有時是中間銀行（BIC）。
• 傭金：SHA/OUR/BEN-選擇誰支付代理服務費用。

3）消息和格式： MT ⇄ ISO 20022（MX）

MT103（客戶信用轉移），MT202 COV（覆蓋），MT199/999（免費形式），MT192/195（召回/停止）。
ISO 20022 (MX): pacs.008 (credit transfer), pacs.009 (FI-to-FI), pacs.004 (return), camt.052/053/054（摘錄/發布）。
許多銀行正在向ISO過渡；保持雙重兼容性（MT輸入/輸出↔內核中的規範模型）。

4) SWIFT gpi и UETR

gpi（全球付款創新）在時間上增加了端到端UETR（UUID）和SLA；給出收回/credited/on-hold狀態。
您在銀行/PSP門戶或API上使用UETR跟蹤器，向玩家/合作夥伴顯示清晰的ETA和延遲原因。
將"payment_id ↔ UETR綁定↔ provider_ref'用於行車記錄和重新配置。

5）截止日期、截止日期和日歷

發送/通訊員→切斷直到切斷-T+0/T+1的機會，否則T+1/T+2。
非STP因素：手動檢查，名稱/地址不匹配，非有效性BIC/IBAN，制裁觸發器，外來貨幣。
考慮這兩個國家的假期和貨幣→保持日歷（TARGET2/US/本地）。

6）委員會和FX： 成本由什麼構成

Model: `Cost per Approved (SWIFT) = bank_fee + correspondent_fee(s) + gpi_fee (если есть) + FX_margin + ops_cost (investigations/R-возвраты)`.

SHA/OUR/BEN:

SHA-雙方向銀行付款（違約）。
OUR-您涵蓋所有傭金，受益人收到的金額恰好（更貴）。
BEN-受益人支付一切（很少適合B2C）。
外匯保證金：報價來源，利差，截止時間；記錄會計和爭議的課程/時間（quote id）。

7）合規性： 制裁，KYC/KYB，EDD

制裁/PEP/adverse：篩選發件人/受益人/中介銀行；名稱/地址/國家/地區匹配項→ hold/EDD。
End-use/SoF/SoW：付款目的請求（invoice/合同）和觸發資金來源（金額/地理/模式）。
RBA 限制/velocity： caps per-tx/per-day,新道具→強化驗證。
付款數據（備用信息）必須準確：目的，合同編號，發票。

8）道具驗證和STP質量

IBAN/Luhn/MOD97，BIC驗證，收件人地址（城市/國家/地區），目標代碼（需要）。
Payee的名稱Check/Confirmation對應項-如果可從銀行/PSP獲得。
Whitelist與TTL和重構的合作夥伴道具。
STP規則：字段越飽滿,手動檢查和退貨越少。

9）拒絕，退款和調查（調查）

• 發送/接受之前的Reject（驗證未通過）。
• 入場後返回（後期檢查，帳戶關閉，制裁/EDD）-ISO pacs。004或MT Return。
• Recall/Stop&Recall：要求撤回付款（未得到保證）。
• 調查：通過MT199/999/MX camt/case，gpi門戶進行通信。
• 實踐：存儲原因代碼/文本、SLA處理、信件模板。

10）產品中的線程（參考）

10.1 Inbound（接收資金）

1.簽發詳細信息：BIC/IBAN/beneficiary name/address，有時是中間BIC。
2.客戶/合作夥伴發送MT103/pacs。008 →你的銀行。
3.Webhook/摘錄（camt。053/MT940）→余額，通過「EndToEndId/UETR/Remit」進行映射。
4.KINWA/KUS/制裁-後期控制，並在必要時恢復/返回。

10.2 Outbound（付款）

1.申請→澳洲聯儲審計/制裁，道具驗證，選擇SHA/OUR/BEN 和貨幣/FX。
2.通過API/銀行-客戶端發送→收到UETR。
3.Gpi監視，狀態，ETA溝通，返回/調查處理。
4.T+0/T+1的重構。

11）Leiger，出院和重構

標識符：「payment_id ↔ UETR ↔ bank_ref ↔ EndToEndId/RemittanceInfo」。
摘錄：ISO camt。052/053/054或MT MT940/942；傭金/貨幣/驗證日期。
T+0/T+1對賬：金額，FX，傭金，「懸掛」（未分類的線路）→調查隊列。
報告/審計：不變的日誌、外匯匯率來源、交易對手數據版本。

12）管弦樂、feilover和SLA

主要貨幣的多銀行/多個PSP；後備通訊員。
路由規則：按貨幣、國家、規模、銀行的SLA、價值（fee+FX）。
切斷預告片（假期考慮）。
SLA基準：自動案例-≤ T+1，手動EDD-≤ T+2-T+3；gpi狀態更新-近實時。

13） UX和通信

透明的ETA和因素解釋（銀行/國家/貨幣，切斷，OUR/SHA）。
在合作夥伴/VIP辦公室中顯示UETR鏈接/狀態。
輸入詳細信息的清晰字段、地址/IBAN/BIC格式的提示、OUR‐komissiyakh警告。
return/recall/investigation響應模板。

14）度量和OKR

Success/Approval Rate SWIFT, доля STP.

Time-to-Funds/Time-to-Payout p50/p95.

gpi visibility%（當前跟蹤的支付份額）。
Return/Recall/調查率，平均調查時間。

每人成本提高（fee+FX+ops），FX利差為b.p.

False-positive compliance，手工案例的比例。

15）反模式

每種貨幣的一家銀行/通訊員→ SPOF。
不完整的詳細信息（地址/名稱/目的）→手動檢查和返回。
忽略切斷/假期，沒有調度程序。
非偽造匯率/報價時間→ FX爭議。
MIX PII 標誌和無標記支付/RBAC。
沒有映射「payment_id ↔ UETR」 →「迷失」的軌道和劄幌的混亂。

16）實施清單（簡短）

• 按目標貨幣開列的賬戶和通訊線；2+合作夥伴銀行。
• MT/ISO 20022核心規範模型；camt的解析器。052/053/054和MT940/942。
• gpi/UETR整合，狀態的行列，通知。
• IBAN/BIC驗證，地址；惠特利斯特道具；選擇SHA/OUR/BEN。
• FX政策：報價來源、提交、差價限制、日誌。
• 制裁/KYC/KYB/RBA/EDD；文檔模板和案例管理。
• 剪裁和節假日編排；成本路由/SLA。
• Leiger和T+0/T+1重構；unmatched隊列；報告。
• 花花公子回歸/回顧/調查；signed webhooks,等效性。
• Sapport培訓：gpi狀態，原因代碼，FX/傭金通信。

17）摘要

SWIFT是iGaming國際支付的「重型火炮」。使用gpi/UETR構建多銀行輪廓,保持嚴格的FX和傭金記錄,遵守制裁/EDD,自動化T+1重新配置,並向客戶展示透明的ETA和狀態。然後，即使是復雜的填字遊戲付款也將是可預測的，符合要求和經濟管理的。