FX : risques de conversion et de change

1) Pourquoi gérer FX dans iGaming

Rapport P et L précis : où se produit le rendement/perte FX (dépôts, conclusions, settlement PSP, réserves).
Juste ND/GRR/NGR : un seul rapport de currency sans « réévaluation rétroactive ».
Liquidité et cache-flow : le funding dans la monnaie A, les paiements en B - il faut une prévision et un hedge.
Conformité/taxes : origine transparente des cours et vérification des traces.

2) Points clés où le FX naît

1. Portefeuille de jeu vs monnaie de dépôt : normalisation dans la monnaie de portefeuille/rapport.
2. Capture/settle chez PSP : un cours « historique » est enregistré pour ND.
3. Funding (inscription à une banque) : un taux de change/monnaie différent et un effet FX secondaire sont possibles.
4. Withdrawals : conversion lors du paiement au joueur.
5. Rolling réserve et sanctions des régimes : les prélèvements/sorties peuvent être dans une autre monnaie.
6. Crypto : estimation par VWAP/médiane au moment du settle/funding.

3) Sources de cours et règles de normalisation

FX source : les fournisseurs de référence (par exemple CME/Refinitiv/BCE) sont prioritaires, la banque/PSP est une réserve.
Quote policy: `mid`, `bid/ask` или `mid ± spread_bps`. Le mid + explicite 'spread _ bps' est plus souvent utilisé pour la comptabilité.
Timestamp : cours au moment de l'événement de reconnaissance (habituellement "settled _ at'pour ND ; optionnellement 'funded _ at'pour la banque-comptabilité).
No restoration : les MN passées ne sont pas surestimées lorsque les cours changent ; reval est fait séparément comme unrealized FX.
Précision : stocker 8-10 caractères dans le cours FX, les sommes d'argent sont en unités mineures (integers) + échelle.

4) Formules et exemples

4. 1. Conversion de base

amount_reporting = round(amount_original fx, scale_ccy_rep)

4. 2. Taux de change croisé (par l'intermédiaire d'une monnaie d'ancrage, par exemple EUR)

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

Il est important de stocker l'itinéraire des cours (triangulation) dans « meta » pour l'audit.

4. 3. Séparation du spread et des frais PSP

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

Stockez le FX efficace et le FX de référence pour mesurer la marge d'impact de PSP.

4. 4. Exemple (chaîne à double conversion)

Le joueur dépose 100 GBP. Reporting — EUR.
На `settled_at`: `GBP→EUR = 1. 1700` → `ND_dep = 117. 00 EUR`.
PSP finance la banque en USD demain : 'GBP→USD = 1. 3000 ', la banque détient un compte en USD.
Pour la comptabilité FI, fixez le cours secondaire 'USD→EUR' sur 'funded _ at' (par exemple 0. 9200) pour voir le FX realized entre settle et funding si la position de trésorerie est réévaluée.

5) DCC, conversion PSP et « qui décide du cours »

DCC (Dynamic Currency Conversion) côté merchant/PSP : le cours est affiché au joueur à l'avance, mais la marge est plus élevée.
Conversion PSP : Le PSP accepte la monnaie du joueur, la convertit en monnaie du merchant à son taux de change. La transparence du spread est critique.
Merchant-conversion : Le merchant accepte le multi-devise (multi-MID/multi-devis), la conversion est effectuée par la banque/trigerie au meilleur taux (généralement plus rentable, mais plus difficile sur le plan opérationnel).
Recommandation : enregistrer les conversion_owner ('DCC', 'PSP', 'MERCHANT') et comparer les TCO (spred + fee).

6) Crypto : évaluation et volatilité

L'estimation selon VWAP pour la fenêtre courte autour ' settled_at ' (par exemple, ±5 des minutes), avec l'indication de la source (la bourse/provider).
Stockez : 'price _ usd',' price _ eur ',' source ',' window ',' paire '(par exemple,' USDT/USDC/BTC ').
Pour le funding dans les steaks/fiat - la deuxième couche de FX.
Spécificité : Spike, delisting, on-chain fees - à prendre en compte dans « meta » et alerts.

7) Comptabilisation de FX dans les rapports : realized vs unrealized

Le FX realized est la différence « fermée » par le flux de trésorerie (entre le taux de comptabilisation et le taux de change/revenu effectif).
Unrealized FX - Réévaluation des soldes des comptes/réserves multi-devises à la fin du jour/mois.
Répartissez sur différents comptes GL : 'FX _ realized', 'FX _ unrealized'.
Pour les analyses ND/produits, utilisez le cours historique de l'événement (ne surestimez pas).

8) Types d'expositions FX et comment les fermer

Transaction exposition : non-correspondance des devises d'entrée/sortie (dépôt EUR → retrait TRY).

Mesures : hedge naturel (choisir la monnaie des paiements), enveloppe rapide selon les règles.
Traduction exposition : multi-comptes et réserves dans différentes monnaies → EoD/EoM reval.
Exposition économique : dépendance à long terme de la marge par rapport au taux de change (mix GEO, fournisseurs de jeux).

Mesures : forwards/NDF, options (collars), équilibrage GEO et fournisseurs.

9) Processus et politiques de Trégerie

Politique FX : limites par position ouverte pour chaque monnaie (par exemple, pas plus de 20 % du chiffre d'affaires hebdomadaire).
Règles d'exécution : volume minimal de la transaction, spreads, liste des contreparties.
Forecasting : 7/30/90 jours prévisions de besoins nets par devises (dépôts − conclusions − impôts − OREH).
Hedge comptabilité (si nécessaire) : documenter la relation « hedge position ↔ risque ».
Calendrier des fêtes : affecte la réserve de funding/rolling et la « fermeture » de FX.

10) Données et modèle (simplifié)

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) Rapprochement et contrôle de la qualité

11. 1. Alignement de « nos » cours avec PSP/banque

Mappez 'fx _ effective' (de settlement) à 'fx _ reference' (de votre manuel).
Alert si '| spread _ bps |> threshold' (par exemple,> 80 bps pour les majeurs).

11. 2. Qualité de la source des cours

Stale-rates : si 'now - fx_timestamp> X minutes "à l'arrivée de l'événement - alert et source d'urgence.
Incohérences de triangulation : 'fx (A→B) fx (B→C)' vs'fx (A→C) '- alert, logiez la divergence dans bps.

12) Exemples de modèles SQL

12. 1. Normaliser les transactions dans la monnaie de déclaration

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. Décomposition de l'effet FX PSP (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. Réévaluation quotidienne des soldes multi-devises (FX unrealized)

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 et dashboards

FX Slippage (bps) : différence effective vs référence par PSP/méthode/MID.
Realized FX P&L (jour/semaine/mois) et Unrealized FX (EoD/EoM).
Position Open FX par devises vs limites de politique.
Hedge Ratio : part de la position couverte (forwards/NDF/options).
Stale-rate Incidents и Triangulation Mismatch.
Spread % of Volume (combien de FX valait par rapport au volume traité).

14) Alertes et seuils

Taux Stale : pas de taux actuel> N minutes au pic du trafic - P1.
Spread spike : 'spread _ bps' est au-dessus du seuil pour les majeurs/mineurs - P2.
Ouverture de la position breach : dépassement de la limite pour n'importe quelle devise - P1.
FX P&L shock : jour realized FX ci-dessous − X σ historique - enquête.
Crypto price gap : saut> Y % de la fenêtre VWAP - commutation source/pause de l'enveloppe.

15) Meilleures pratiques (en bref)

1. Reconnaître les métriques de ND et de produits selon le taux de settled, sans réévaluation rétrospective.
2. Pour FI/trigerie, gardez le deuxième cours sur le funded_at - vous verrez le FX realized.
3. Fixez toujours les conversion_owner, fx_source, quote_type, spread_bps.
4. Faire la triangulation à travers l'ancre (EUR/USD) avec loging.
5. Séparez realized et unrealized au niveau GL.
6. Dans la crypto, utilisez une fenêtre VWAP plutôt qu'un seul tic.
7. Automatisez les alertes sur les notes stales et l'écart PSP anormal.
8. Prédire le besoin net en devises et utiliser natural hedge + forwards/NDF.

16) Chèque de mise en œuvre

• Répertoire des cours 'ref. fx_rates' avec EOD et intraday, stockage source et quote type.
• Витрины `transactions_flat`, `fx_settlement_view`, `funding_receipts`.
• Mécanicien de triangulation et journal d'itinéraire des cours.
• Comptabilité à deux niveaux de FX (ND/produit vs FI/trigerie).
• Les soldes quotidiens reval multi-devises.
• Dashboards KPI (slippage, open position, FX P&L).
• Politique FX : limites des positions, liste blanche des contreparties, seuils d'alertes.
• Procédure de hedging (forwards/NDF/options) et circulation des documents.

Résumé

FX dans iGaming n'est pas seulement « multiplier le taux par le montant ». C'est tout un système : points de reconnaissance clairs, sources transparentes de cours, comptabilité séparée realized/unrealized, contrôle de l'écart PSP et position ouverte gérée. En introduisant un manuel FX standard, une normalisation « par settle », des procédures reval et une politique FX compréhensible avec des outils spéculatifs, vous retirez la volatilité de la P&L et rendez les flux de trésorerie prévisibles.