マルチカレンシーブックとコース

1）「マルチカレンシーブック」とは"

• ウォレットブック：プレイヤーのアカウント（ゲーム通貨/通貨）。
• 決済書籍：PSP/acquirer（決済通貨）による決済。
• 財務省の本：銀行口座、コンバージョン、ヘッジ取引。
• レポートレジャー：レポーティング通貨の要約（例えば、EUR）製品メトリクスのレトロスペクティブな再評価なし。

各ブックは、取引通貨、プレゼンテーション通貨、および認識時のレートを記録します。

2）通貨とポリシーの階層

1.ベース/レポート通貨-単一のレポート通貨（EURなど）。
2.ウォレット通貨-財布通貨（USD/EUR/TRY/UAHなど）。
3.決済通貨-PSPが送信するもの（例えば、USD）。
4.銀行通貨-マーチャント/トレジャリー口座通貨。

• 製品メトリクス（ND/NGR/ARPPU）-イベントの履歴率（通常は'settled_at'）。
• 財務/財務-さらに、'funded_at'と'payout_at'のコースを修正します。
• 食品表示における「隠された」再評価は禁止されています。

3）コースとそのソース

日中参照（ティック/分）：Refinitiv/ECB/banks-イベントを正規化する。
EOD（終了日）：未実装FX用。
効果的なFX： PSP/銀行ファイルから（実際の変換）。
三角測量：直接見積もりがない場合にアンカー（EURまたはUSD）を通じて。
見積もりポリシー：'mid'…… 'bid/ask'→'mid ± spread_bps'。スプレッドは別々に保存されます。

ストア：'fx_source'、 'fx_pair'、 'fx_rate'、 'fx_timestamp'、 'quote_type'、 'spread_bps'、および三角測量ルート。

4）認識ポイントとコースレイヤー

'authorize_at'-コースを修正しません（キャプチャなしでは認識されません）。
'captured/setted_at'-製品レイヤーとNDの履歴コース。
'funded_at'-1銀行あたりの為替レート（FI/財務省のFXを実現）。
'payout_at'-プレイヤーに支払われたときの料金。
'eod'は非現実的なFXの終日率です。

5）精度、丸め、最小単位

Money-通貨ディレクトリ内のマイナーユニット全体（int）+'scale'。
コース-少なくとも8-10小数点。
丸め：報告のための銀行（半分偶数）；UI-ローカルルール。
'amount_original'、 'amount_wallet'、 'amount_reporting'、 'amount_effective'という別のフィールドを維持します。

6）二重記入項目およびGLカード（簡略化される）

6.1.DEPOSIT_CAPTURED （GBP、報告-EUR）

JT： AR： PSP （GBP）

Ct： プレーヤーバランス（財布によるGBP/EUR）

並行して、'fx_rate_settle （GBP→EUR）'と'amount_reporting'を修正します。

6.2.FUNDING_RECEIVED （USD 1銀行あたり）

Dt： 銀行USD

Ct： AR： PSP GBP（同等によって近い；difference→Realized FX）。

6.3.WITHDRAWAL_PAID （TRY）

免責事項： プレーヤー（TRY）

Ct：銀行TRY（または銀行EUR+変換；difference-realized FX）。

7）データアーキテクチャ（最小モデル）

ref. currencies (
code PK, scale, symbol, is_crypto, is_active
)

ref. fx_rates_intraday (
pair PK, ts PK, rate, quote_type, source, spread_bps, triangulation_meta
)

ref. fx_rates_eod (
pair PK, date PK, rate, source
)

ledger. entries (
entry_id PK, book, -- WALLET      SETTLEMENT      TREASURY      REPORTING debit_account, credit_account,
amount_original, currency_original,
amount_reporting, reporting_currency,
fx_rate_at_settle, fx_source, fx_pair, fx_timestamp,
event_type, event_id, user_id, provider, method,
occurred_at, created_at, meta
)

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

treasury. balances (
date PK, account PK, currency PK, amount
)

dw. transactions_flat (
tx_id PK, user_id, provider, method, type, status,
amount_original, currency_original,
amount_reporting, reporting_currency, fx_rate_at_settle,
settled_at, funded_at, conversion_owner, meta
)

8）正規化の流れ（ETL/ELT）

1.原料のingest→PSPの状態の正規化。
2.'fx_rates_intraday'から'setted_at'への履歴レートの割り当て。
3.希望する元帳（ウォレット/決済）にダブルトランザクションを書き込みます。
4.別の輸入資金と効果的なFX。
5."fx_rates_eod' （treasury-book）による残高の毎日のリバル。
6.店の窓の構造（ND/NGR/LTV）レトロな再評価なし。

9）和解と一貫性

Tx→ファイル：キャプチャ/決済されたすべてのPSPファイルにありました（金額/通貨/日付による）。
ファイル→Tx：ファイル内のすべてが書籍/トランザクションに反映されます。
FXリファレンスと有効：count 'slippage_bps'；しきい値を越えるように警告します。
三角測量のチェック：'A→B B→C' ≈ bps-tolerans内の'A→C'。
Idempotency： 'event_id'および'idempotency_key'-重複に対する保護。

10）頻繁なシナリオとそれらを実行する方法

マルチウォレット：プレイヤーのウォレットはデポジットとは別の通貨にすることができます-レートで内部変換を行います（'conversion_owner='MERCHANT'ポリシー）。
PSP-conversion： PSPマージン分析用に'fx_effective'、 'fx_reference'、 'spread_bps'を格納します。
暗号：VWAPウィンドウスコア；stablesの資金調達はFXの第2層です。
クロスウォレット転送：プラットフォーム内での移動-FX収入なしで、本の間で転送するだけです。

11） SQLテンプレート

11.1.過去のレートで報告通貨への金額の正規化

sql
SELECT t. tx_id,
t. amount_original,
t. currency_original,
r. rate AS fx_rate_at_settle,
ROUND(t. amount_original r. rate, rep. scale) AS amount_reporting
FROM raw. transactions t
JOIN ref. fx_rates_intraday r
ON r. pair = CONCAT(t. currency_original, '/',:reporting_ccy)
AND r. ts = (
SELECT MAX(ts) FROM ref. fx_rates_intraday
WHERE pair = r. pair AND ts <= t. settled_at
)
JOIN ref. currencies rep ON rep. code =:reporting_ccy
WHERE t. settled_at BETWEEN:from AND:to;

11.2.PSPスプレッド測定（有効対参照）

sql
SELECT provider, method, DATE(settled_at) AS d,
SUM(original_amount fx_reference_rate) AS ref_in_reporting,
SUM(settlement_amount_in_reporting)   AS eff_in_reporting,
10000 (SUM(settlement_amount_in_reporting) /
NULLIF(SUM(original_amount fx_reference_rate),0) - 1) AS spread_bps
FROM dw. fx_settlement_view
WHERE settled_at BETWEEN:from AND:to
GROUP BY 1,2,3;

11.3.unrealized FX

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

12） KPIとダッシュボード

PSP/Method/MIDによるFXスリッページ（bps）。
Realized FX P&L（資金調達/支払い）○Unrealized FX （EOD/EOM）。
Open FX Position by currency vs policy limits。
ヒットレート「時間通りに」コース（古いレートのインシデント）。
PSP変換とマーチャント変換とそのTCOの共有。
丸め精度（量の偏差≥ 1マイナーユニット-フラグ）。

13）アラートとしきい値

古いレート：イベント→フォールバックソース/リトレイの時点ではレートがありません。
三角形の不一致：発散>X bps。

Spread spike： 'spread_bps'（メジャー/メジャーの閾値より上）

オープンポジション違反：任意の通貨の上限を超えます。
Revalショック：毎日の再評価<− X σまたは>+X σ-レビュー。

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

1.製品レイヤー（過去のFX）とFI/treasury（資金調達/ペイアウト/reval）を厳密に分離します。
2.マイナーユニットを使用し、コースを高精度に保存します。
3.conversion_ownerをログに記録し、PSPマージンを測定します（効果対参照）。
4.イベントidempotencyと双方向の調整（Tx→FileとFile→Tx）を実装します。
5.三角測量のためのアンカー通貨を保持し、bpsで矛盾を検証します。
6.別のGLでEODプロシージャで残高を再評価します。
7.決済/資金調達にコースを割り当てる場合は、DST/タイムゾーンを検討してください。
8.スケール境界のプロパティベースのテストを定期的にテストします。

15）実装チェックリスト

• 通貨と履歴FXポリシーを定義したレポート。
• コースのソース：日中+EOD、フォールバック、SLAの更新。
• モデルレジャー。エントリー'、'fx_rates_'、'funding_receipts'、'balances'、'transactions_flat'。
• 三角メカニズムとルートログ。
• アルゴリズム：ステールレート、スプレッドスパイク、三角ミスマッチ、オープンポジション違反。
• KPIダッシュボードとPSP/銀行の和解レポート。
• revalプロシージャおよびrealized/unrealized FXのための別のGL。
• 丸めと保管精度のテストセット。

概要

マルチカレンシーブックは、レイヤー分離の規律です。製品の歴史的なFX、トレジャリーの実際、バランスシートのEOD再評価。透明性の高いレートソース、正確なデータモデル、ダブルエントリー、自動化された調整により、アナリティクスから「通貨ノイズ」を排除し、監査を提供し、グローバルな収益化においてFXリスクを管理します。