FX: conversion and foreign exchange risks

1) Why manage FX in iGaming

Accurate P&L reporting: where FX profit/loss arises (deposits, conclusions, PSP settlement, reserves).

Fair ND/GRR/NGR: single reporting currency without "retroactive revaluations."

Liquidity and cash flow: funding in currency A, payments in B - need forecast and hedge.
Compliance/taxes: transparent origin of courses and audit of traces.

2) Key points where FX is born

1. Game wallet vs deposit currency: normalization in wallet/reporting currency.
2. Capture/settle at PSP: a "historical" course is recorded for ND.
3. Funding (crediting to the bank): a different rate/currency and a secondary FX effect are possible.
4. Withdrawals: Conversion when paid to player.
5. Rolling reserve and scheme penalties: write-offs/releases may be in a different currency.
6. Crypto: VWAP score/median at settle/funding.

3) Course sources and normalization rules

FX source: priority reference providers (for example, CME/Refinitiv/ECB), reserve - bank/PSP.
Quote policy: `mid`, `bid/ask` или `mid ± spread_bps`. For accounting, mid + explicit 'spread _ bps' is more often used.
Timestamp: course at the time of the recognition event (usually 'settled _ at' for ND; optional 'funded _ at' for the accounting bank).
No reinstatement: past NDs are not overestimated when rates change; reval is done separately as unrealized FX.
Accuracy: store 8-10 characters in the FX course, monetary amounts - in minor units (integers) + scale.

4) Formulas and Examples

4. 1. Basic conversion

amount_reporting = round(amount_original fx, scale_ccy_rep)

4. 2. Cross rate (via anchor currency, e.g. EUR)

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

It is important to store the course route (triangulation) in 'meta' for audit.

4. 3. Split spread and PSP commission

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

Store effective FX and reference FX to measure PSP implicit margin.

4. 4. Example (double conversion chain)

The player will deposit 100 GBP. Reporting — EUR.
На `settled_at`: `GBP→EUR = 1. 1700` → `ND_dep = 117. 00 EUR`.
PSP funds the bank in USD tomorrow: 'GBP→USD = 1. 3000 ', the bank holds an account in USD.
For FI accounting, fix the secondary rate 'USD→EUR' to 'funded _ at' (for example, 0. 9200) to see the realised FX between settle and funding if the cash position is overvalued.

5) DCC, PSP conversion and "who decides the rate"

DCC (Dynamic Currency Conversion) on the merchant/PSP side: the course is shown to the player in advance, but the margin is higher.
PSP-conversion: PSP accepts the player's currency, converts it to the merchant's currency at its own rate. The transparency of the spread is critical.
Merchant-conversion: the merchant accepts multi-currency (multi-MID/multi-account), the conversion is performed by the bank/trader at the best rate (usually more profitable, but more difficult operationally).
Recommendation: fix conversion_owner ('DCC', 'PSP', 'MERCHANT') and compare TCO (spread + fee).

6) Crypto: Valuation and Volatility

VWAP score in a short window around 'settled _ at' (for example, ± 5 minutes), indicating the source (exchange/provider).
Store: 'price _ usd', 'price _ eur', 'source', 'window', 'pair' (for example, 'USDT/USDC/BTC').
For funding in stables/fiat, the second FX layer.
Specificity: adhesions, delisting, on-chain fees - take into account in 'meta' and alerts.

7) FX accounting in reporting: realized vs unrealized

Realized FX - difference "closed" by cash flow (between the recognition rate and the actual exchange/receipt rate).
Unrealized FX - revaluation of balances on multicurrency accounts/reserve at the end of the day/month.
Post to different GL accounts: 'FX _ realized', 'FX _ unrealized'.
For ND/Product Analytics, use the historical event rate (do not overestimate).

8) FX exposure types and how to close them

Transaction exposure: mismatch of input/output currencies (EUR deposit → TRY output).

Measures: natural hedge (select the currency of payments), fast envelope according to the rules.
Translation exposure: multi-accounts and reserves in different currencies → EoD/EoM reval.
Economic exposure: long-term dependence of margin on the course (GEO-mixes, game providers).

Measures: forwards/NDF, options (collars), balancing GEO and suppliers.

9) Treasure processes and policies

FX policy: limits on the open position for each currency (for example, not more than 20% of the weekly turnover).
Execution rules: minimum deal volume, threshold spreads, list of counterparties.
Forecasting: 7/30/90-day net demand forecast by currency (deposits − conclusions − taxes − OREX).
Hedge accounting (if necessary): documentation of hedge position ↔ risk relationships.

Holiday Calendar: Affects funding/rolling reserve and FX "close."

10) Data and model (simplified)

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) Reconciliation and quality control

11. 1. Coordination of "our" courses with PSP/bank

Match 'fx _ effective' (from settlement) to 'fx _ reference' (from your directory).
Alert if '| spread _ bps |> threshold' (for example,> 80 bps for majors).

11. 2. Course Source Quality

Stale-rates: if 'now - fx_timestamp> X minutes' when the event arrives - alert and emergency source.
Inconsistencies triangulation: 'fx (A→B) fx (B→C)' vs' fx (A→C) '- alert, log the discrepancy in bps.

12) Examples of SQL templates

12. 1. Normalization of transactions to reporting currency

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 effect decomposition (effective vs reference)

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. Daily revaluation of multicurrency balances (unrealized 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 and dashboards

FX Slippage (bps): effective vs reference difference by PSP/method/MID.
Realized FX P&L (day/week/month) and Unrealized FX (EoD/EoM).
Open FX Position by currency vs policy limits.
Hedge Ratio (forwards/NDF/options).
Stale-rate Incidents и Triangulation Mismatch.
Spread% of Volume (how much FX cost relative to processed volume).

14) Alerts and thresholds

Stale rates: no current course> N minutes in peak traffic - P1.
Spread spike: 'spread _ bps' above threshold for majors/minors - P2.
Open position breach: exceeding the limit for any currency - P1.
FX P&L shock: daily realized FX below − X σ historical - investigation.
Crypto price gap: jump> Y% of VWAP window - source switch/envelope pause.

15) Best practices (short)

1. Recognize ND and product metrics at the settled rate, without retrospective revaluation.
2. For FI/trejeri, keep the second course on the funded_at - you will see realized FX.
3. Always fix conversion_owner, fx_source, quote_type, spread_bps.
4. Make triangulation through an anchor (EUR/USD) with logging.
5. Separate realized and unrealized at the GL level.
6. In crypto, use a VWAP window, not a single tick.
7. Automate alerts to stale rates and abnormal PSP spread.
8. Forecast net requirements by currency and use natural hedge + forwards/NDF.

16) Implementation checklist

• Course Reference 'ref. fx_rates' with EOD and intraday, source storage and quote type.
• Витрины `transactions_flat`, `fx_settlement_view`, `funding_receipts`.
• Triangulation mechanics and course route log.
• Two-level FX accounting (ND/product vs FI/trejeri).
• Daily reval of multicurrency balances.
• KPI dashboards (slippage, open position, FX P&L).
• FX policy: position limits, white-list counterparties, alert thresholds.
• Hedging procedure (forwards/NDF/options) and workflow.

Summary

FX in iGaming is not only a "multiply by sum rate." This is a whole system: clear points of recognition, transparent sources of courses, split accounting realized/unrealized, PSP spread control and managed open position. By implementing the standard FX handbook, settle normalization, reval procedures and understandable FX policies with hedge instruments, you remove volatility from P&L and make cash flows predictable.