FX：転換と為替リスク

1） iGamingでFXを管理する理由

正確なP&Lレポート：FX損益（預金、結論、PSP決済、準備金）が発生する場所。
公正なND/GRR/NGR：「遡及的な再評価」なしで単一の報告通貨。
流動性とキャッシュフロー：通貨Aでの資金調達、Bでの支払い-予測とヘッジが必要です。
コンプライアンス/税金：コースの透明な起源とトレースの監査。

2） FXが生まれるポイント

1.ゲームウォレットと預金通貨：ウォレット/レポート通貨の正規化。
2.PSPでのキャプチャ/セトル：NDの「履歴」コースが記録されます。
3.資金調達（銀行へのクレジット）：異なるレート/通貨と二次FX効果が可能です。
4.出金：プレイヤーに支払われたときの変換。
5.ローリングリザーブとスキームの罰則：ライトオフ/リリースは異なる通貨になることがあります。
6.暗号：VWAPスコア/決済/資金調達時の中央値。

3）コースのソースと正規化のルール

FXソース：優先リファレンスプロバイダ（CME/Refinitiv/ECBなど）、リザーブ-銀行/PSP。
見積ポリシー：'mid'、 'bid/ask'、 'mid' ± spread_bps'。会計のために、mid+explicit 'spread_bps'がより頻繁に使用されます。
タイムスタンプ：認識イベント時のコース（通常はNDの場合は'sreted_at'；会計銀行のオプション'funded_at'）。
いいえ復帰：過去のNDは、料金が変更されたときに過大評価されません。revalは非現実的なFXとして別々に行われます。
精度：FXコースに8-10文字、金額-マイナーユニット（整数）+スケールで保存します。

4）数式と例

4.1.基本的な変換

amount_reporting = round(amount_original fx, scale_ccy_rep)

4.2.クロスレート（アンカー通貨経由、EURなど）

fx(GBP→UAH) = fx(GBP→EUR) fx(EUR→UAH)

監査のためには、コースのルート（三角測量）を'meta'に格納することが重要です。

4.3.スプリットスプレッドとPSPコミッション

fx_effective = settlement_amount_in_rep / original_amount spread_bps  = (fx_effective / fx_reference - 1) 10_000 fee_fx    = settlement_fee_in_rep (если отдельно)

PSPの暗黙的なマージンを測定するために効果的なFXと参照FXを保存します。

4.4.例（二重変換チェーン）

プレイヤーは100 GBPを入金します。レポート-EUR。
'setted_at'： 'GBP→EUR=1。1700'→'ND_dep=117。00 EUR'。
PSPは明日USDで銀行に資金を供給します：'GBP→USD=1。3000'、銀行はUSDで口座を保有しています。
FI会計の場合、セカンダリ・レート'USD→EUR'を'funded_at'に修正します（例えば、0。現金ポジションが過大評価されている場合は、決済と資金調達の間の実現されたFXを見るために9200）。

5） DCC、 PSP変換と「レートを決定する人」

商人/PSP側のDCC （Dynamic Currency Conversion）：コースは事前にプレイヤーに表示されますが、マージンは高くなります。
PSP-conversion： PSPはプレイヤーの通貨を受け取り、独自のレートで商人の通貨に変換します。広がりの透明性は重要です。
商人変換：商人は複数の通貨（複数のMID/マルチアカウント）を受け入れ、変換は銀行/トレーダーによって最高のレートで実行されます（通常はより収益性が高いが、操作上はより困難です）。
推奨事項：conversion_owner （'DCC'、 'PSP'、 'MERCHANT'）を修正し、TCO（スプレッド+料金）を比較します。

6）暗号： 評価とボラティリティ

VWAPスコアは'settled_at'の周りの短いウィンドウで（例えば、± 5分）、ソース（exchange/provider）を示します。
ストア：'price_usd'、 'price_eur'、 'source'、 'window'、 'pair'（例えば、'USDT/USDC/BTC'）。
stables/fiatの資金調達のために、第2のFX層。
特異性：付着、デリスティング、オンチェーン手数料-'meta'とアラートを考慮してください。

7）レポートにおけるFX会計： 実現されたvs未実現

FXを実現-キャッシュフロー（認識率と実際の為替/レシート率の間）による「クローズ」差。
Unrealized FX-1日/月の終わりにマルチカレンシーアカウント/予約の残高の再評価。
異なるGLアカウントに投稿：'FX_realized'、 'FX_unrealized'。
ND/Product Analyticsでは、過去のイベントレートを使用します（過大評価しないでください）。

8） FX露出タイプとそれらを閉じる方法

取引エクスポージャー：入出力通貨（EURデポジット→TRY出力）の不一致。

対策：自然なヘッジ（支払いの通貨を選択）、ルールに従って高速封筒。
翻訳エクスポージャー：異なる通貨でのマルチアカウントと準備金→EoD/EoM reval。
経済的エクスポージャー：コース（GEOミックス、ゲームプロバイダー）へのマージンの長期依存。

対策：フォワード/NDF、オプション（襟）、GEOとサプライヤーのバランス。

9）トレジャープロセスとポリシー

FXポリシー：各通貨のオープンポジションの制限（例えば、毎週の売上高の20％以下）。
実行ルール：最小取引量、しきい値スプレッド、取引先のリスト。
予測：通貨による7/30/90日純需要予測（預金−結論−税金− OREX）。
ヘッジアカウンティング（必要に応じて）：ヘッジポジション↔リスク関係のドキュメント。
ホリデーカレンダー：資金調達/ローリングリザーブとFXに影響を与える「クローズ」。

10）データとモデル（簡略化）

payments. transactions (
id, user_id, provider, method, type, status,
amount_original, currency_original, -- event amount and currency amount_wallet, wallet_currency, -- domestic gaming currency (if different)
reporting_currency, amount_reporting, - the sum in reporting currency of fx_source, fx_pair, fx_timestamp, fx_rate, - a course at the time of the event (usually settled_at)
fx_quote_type, fx_spread_bps, fx_reference_rate -- measurement of spread/quotation type settled_at, funded_at, conversion_owner, meta
)

treasury. funding_receipts (
funding_id, provider, bank_account, currency, amount,
received_at, value_date, fx_to_reporting, amount_reporting, meta
)

treasury. fx_reval_ledger (
id, date, currency, position_amount, rate_eod, amount_reporting_eod,
prev_rate_eod, reval_diff, type -- UNREALIZED/REALIZED
)

11）和解と品質管理

11.1.PSP/銀行との「私たちの」コースの調整

「fx_effective」（決済から）を「fx_reference」（ディレクトリから）にマッチさせます。
'| spread_bps |> threshold'の場合に警告します（たとえば、メジャーの場合は>80 bps）。

11.2.コースのソース品質

古いレート：イベントが到着したときに'now-fx_timestamp> X minutes'の場合、アラートと緊急ソース。
一貫性のない三角化：'fx （A→B） fx （B→C）' vs 'fx （A→C）'-アラート、bpsでの不一致を記録します。

12） SQLテンプレートの例

12.1.通貨報告へのトランザクションの正常化

sql
INSERT INTO dw. transactions_flat (...)
SELECT t. id, t. user_id, t. provider, t. method, t. type, t. status,
t. amount_original, t. currency_original,
t. reporting_currency,
ROUND(t. amount_original r. fx_rate, c. scale) AS amount_reporting,
r. source AS fx_source, r. pair AS fx_pair, r. fx_rate,
r. quote_type AS fx_quote_type, r. spread_bps,
t. settled_at, t. funded_at, t. conversion_owner, t. meta
FROM raw. transactions t
JOIN ref. fx_rates r
ON r. pair = CONCAT(t. currency_original, '/', t. reporting_currency)
AND r. ts = (SELECT MAX(ts) FROM ref. fx_rates
WHERE pair=r. pair AND ts <= t. settled_at)
JOIN ref. currencies c ON c. code = t. reporting_currency
WHERE t. settled_at BETWEEN:from AND:to;

12.2.PSP FX効果分解（効果対参照）

sql
SELECT provider, method, DATE(settled_at) AS d,
SUM(amount_reporting)                  AS amount_rep_ref,
SUM(settlement_amount_in_rep)              AS amount_rep_eff,
(SUM(settlement_amount_in_rep) - SUM(amount_reporting)) AS fx_slippage,
10000 (SUM(settlement_amount_in_rep) / NULLIF(SUM(original_amountfx_reference_rate),0) - 1) AS spread_bps
FROM dw. fx_settlement_view
WHERE settled_at BETWEEN:from AND:to
GROUP BY 1,2,3
ORDER BY d;

12.3.マルチカレンシーバランスの毎日の再評価（未実現FX）

sql
INSERT INTO treasury. fx_reval_ledger (date, currency, position_amount, rate_eod, amount_reporting_eod, prev_rate_eod, reval_diff, type)
SELECT
:eod_date AS date,
bal. currency,
bal. amount AS position_amount,
r_eod. fx_rate AS rate_eod,
bal. amount r_eod. fx_rate AS amount_reporting_eod,
COALESCE(l. prev_rate_eod, r_eod. fx_rate) AS prev_rate_eod,
bal. amount (r_eod. fx_rate - COALESCE(l. prev_rate_eod, r_eod. fx_rate)) AS reval_diff,
'UNREALIZED'::text
FROM treasury. balances bal
JOIN ref. fx_rates_eod r_eod
ON r_eod. pair = CONCAT(bal. currency, '/',:rep_ccy) AND r_eod. date =:eod_date
LEFT JOIN LATERAL (
SELECT rate_eod AS prev_rate_eod
FROM treasury. fx_reval_ledger
WHERE currency = bal. currency AND date =:eod_date - INTERVAL '1 day'
ORDER BY date DESC LIMIT 1
) l ON TRUE;

13） KPIとダッシュボード

FX Slippage （bps）： PSP/method/MIDによる有効なvs参照差。
FX P&L（曜日/週/月）と未実現FX （EoD/EoM）を実現。
Open FX Position by currency vs policy limits。
ヘッジ比（forwards/NDF/options）。
古いレートのインシデントトライアングレーションのミスマッチ。
ボリュームのスプレッド％（処理されたボリュームに対するFXコスト）。

14）アラートとしきい値

古いレート：現在のコースはありません>ピークトラフィックでN分-P1。
スプレッドスパイク：'spread_bps'メジャー/未成年者のしきい値の上-P2。
オープンポジション違反：任意の通貨-P1の上限を超えます。
FX P&Lショック：毎日− X以下のFXを実現しましたσ歴史的-調査。
暗号価格ギャップ：ジャンプ>VWAPウィンドウのY％-ソーススイッチ/エンベロープの一時停止。

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

1.レトロスペクティブの再評価なしに、決済レートでNDと製品指標を認識します。
2.FI/trejeriの場合は、funded_atの2番目のコースを維持してください-あなたは実現されたFXが表示されます。
3.常にconversion_owner、 fx_source、 quote_type、 spread_bpsを修正します。
4.ロギングでアンカー（EUR/USD）を通して三角測量を行います。
5.別のGLレベルで実現され、未実現。
6.暗号では、VWAPウィンドウを使用します。
7.古いレートと異常なPSPスプレッドへのアラートを自動化します。
8.通貨でネット要件を予測し、自然なヘッジ+フォワード/NDFを使用します。

16）実装チェックリスト

• Course Reference 'ref。 EODとintraday、ソースストレージと引用タイプのfx_rates'。
• 'transactions_flat'、 'fx_settlement_view'、 'funding_receipts'。
• 三角メカニズムとコースルートログ。
• 2レベルFX会計（ND/製品 vs FI/trejeri）。
• マルチカレンシーバランスの毎日の復活。
• KPIダッシュボード（スリッページ、オープンポジション、FX P&L）。
• FXポリシー：位置制限、ホワイトリスト取引相手、アラートしきい値。
• ヘッジ手順（forwards/NDF/options）とワークフロー。

概要

iGamingのFXは「合計レートで乗算する」だけではありません。"これはシステム全体です：認識の明確なポイント、コースの透明なソース、スプリットアカウントの実現/非現実化、PSPスプレッドコントロール、オープンポジションの管理。標準のFXハンドブックを実装し、正規化を解決し、リバルプロシージャとヘッジインストゥルメントで理解可能なFXポリシーを実装することで、P&Lからボラティリティを除去し、キャッシュフローを予測可能にします。