FX: Umrechnungs- und Wechselkursrisiken

1) Warum FX in iGaming verwalten

Genaue P & L-Berichterstattung: wo der FX-Gewinn/Verlust entsteht (Einlagen, Schlussfolgerungen, PSP-Settlement, Reserven).
Faire ND/GRR/NGR: Einheitliche Berichtswährung ohne „rückwirkende Neubewertung“.
Liquidität und Cash Flow: Funding in Währung A, Auszahlungen in B - Prognose und Hedge notwendig.
Compliance/Steuern: Transparente Herkunft der Kurse und Prüfung der Spuren.

2) Schlüsselpunkte, an denen FX geboren wird

1. Gaming Wallet vs Einzahlungswährung: Normalisierung in Wallet/Berichtswährung.
2. Capture/settle bei der PSP: Der „historische“ Kurs für das ND steht fest.
3. Funding (Gutschrift bei der Bank): Ein anderer Kurs/Währung und sekundärer FX-Effekt sind möglich.
4. Withdrawals: Konvertierung bei Auszahlung an den Spieler.
5. Rollreserve und Strafen von Regelungen: Abschreibungen/Freigaben können in einer anderen Währung erfolgen.
6. Krypto: Bewertung durch VWAP/Median zum Zeitpunkt der Einstellung/Finanzierung.

3) Kursquellen und Normalisierungsregeln

FX-Quelle: Referenzanbieter (z. B. CME/Refinitiv/EZB) haben Vorrang, Reserve - Bank/PSP.
Quote policy: `mid`, `bid/ask` или `mid ± spread_bps`. Für die Buchhaltung wird häufiger mid + explizit 'spread _ bps' verwendet.
Zeitstempel: Kurs zum Zeitpunkt des Anerkennungsereignisses (normalerweise' settled _ at 'für ND; optional 'funded _ at' für Bank-Accounting).
Kein Restatement: Vergangene NDs werden nicht überbewertet, wenn sich die Kurse ändern; reval wird separat als unrealized FX durchgeführt.
Genauigkeit: 8-10 Zeichen im FX-Kurs speichern, Geldbeträge in minor units (integers) + scale.

4) Formeln und Beispiele

4. 1. Basiskonvertierung

amount_reporting = round(amount_original fx, scale_ccy_rep)

4. 2. Cross-Rate (über eine Ankerwährung, z.B. EUR)

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

Es ist wichtig, die Route der Kurse (Triangulation) in 'meta' für die Prüfung zu speichern.

4. 3. Trennung von Spread und PSP-Provision

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

Speichern Sie effective FX und reference FX, um die implicit-Marge des PSP zu messen.

4. 4. Beispiel (Kette mit doppelter Konvertierung)

Der Spieler hinterlegt 100 GBP. Reporting — EUR.
На `settled_at`: `GBP→EUR = 1. 1700` → `ND_dep = 117. 00 EUR`.
Die PSP finanziert die Bank morgen in USD: 'GBP→USD = 1. 3000', hält die Bank ein Konto in USD.
Für die FI-Buchhaltung fixieren Sie auch den Sekundärkurs' USD→EUR 'auf' funded _ at'(z.B. 0. 9200), um den realisierten FX zwischen settle und funding zu sehen, wenn die Cash-Position überbewertet ist.

5) DCC, PSP-Konvertierung und „wer entscheidet den Kurs“

DCC (Dynamic Currency Conversion) auf der Merchant-/PSP-Seite: Der Kurs wird dem Spieler im Voraus angezeigt, aber die Marge ist höher.
PSP-Konvertierung: Die PSP akzeptiert die Währung des Spielers, wandelt sie zu ihrem Wechselkurs in die Währung des Merchants um. Die Transparenz des Spreads ist kritisch.
Merchant-Conversion: Merchant akzeptiert Multi-Currency (Multi-MID/Multi-Accounts), die Konvertierung wird von der Bank/Treasury zum besten Kurs durchgeführt (in der Regel profitabler, aber operativ schwieriger).
Empfehlung: Fixieren Sie die conversion_owner ('DCC', 'PSP', 'MERCHANT') und vergleichen Sie die TCO (Spread + Fee).

6) Krypto: Bewertung und Volatilität

VWAP-Score für ein kurzes Fenster um 'settled _ at' (z. B. ± 5 Minuten), mit Angabe der Quelle (Börse/Anbieter).
Speichern Sie: 'price _ usd', 'price _ eur', 'source', 'window', 'pair' (z.B. 'USDT/USDC/BTC').
Für die Finanzierung in Steables/Fiat - die zweite Schicht von FX.
Besonderheiten: Verwachsungen, Delistings, On-Chain-Fees - in 'meta' und Alerts berücksichtigen.

7) FX Accounting im Reporting: realized vs unrealized

Realized FX - die Differenz, die durch den Cashflow „geschlossen“ wird (zwischen dem Anerkennungskurs und dem Kurs des tatsächlichen Austauschs/Eingangs).
Unrealized FX - Neubewertung von Salden auf Multiwährungskonten/Reserve am Ende des Tages/Monats.
Verteilen Sie auf verschiedene GL-Konten: 'FX _ realized', 'FX _ unrealized'.
Verwenden Sie für ND/Product Analytics den historischen Verlauf des Ereignisses (nicht überschätzen).

8) Arten von FX-Belichtung und wie man sie schließt

Transaction Exposure: Nichtübereinstimmung der Ein-/Ausstiegswährungen (EUR-Einzahlung → TRY-Auszahlung).

Maßnahmen: natürliche Hedge (wählen Sie die Währung der Zahlungen), schnelle Umschlag nach den Regeln.
Translation Exposure: Multi-Konten und Reserven in verschiedenen Währungen → EoD/EoM Reval.
Wirtschaftliche Exposition: langfristige Abhängigkeit der Marge vom Kurs (GEO-Mixe, Spieleanbieter).

Maßnahmen: Vorwärts/NDF, Optionen (Kollare), Ausgleich GEO und Lieferanten.

9) Treasury-Prozesse und Richtlinien

FX-Richtlinie: Grenzen für die offene Position für jede Währung (z. B. nicht mehr als 20% des wöchentlichen Umsatzes).
Ausführungsregeln: Mindesthandelsvolumen, Spreads, Liste der Kontrahenten.
Prognose: 7/30/90-Tage-Prognose des Nettobedarfs nach Währungen (Einlagen − Schlussfolgerungen − Steuern − NUSS).
Hedge Accounting (falls erforderlich): Dokumentation der Beziehung „Hedge-Position ↔ Risiko“.
Ferienkalender: Betrifft Funding/Rolling Reserve und „Closing“ FX.

10) Daten und Modell (vereinfacht)

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) Abstimmung und Qualitätskontrolle

11. 1. Abstimmung „unserer“ Kurse mit PSP/Bank

Ordnen Sie' fx _ effective'(von settlement) zu 'fx _ reference' (von Ihrer Referenz).
Alert, wenn'| spread _ bps |> threshold'(z. B.> 80 bps für Dur).

11. 2. Qualität der Kursquelle

Stale-Preise: wenn 'jetzt - fx_timestamp> X Minuten' bei der Ankunft des Ereignisses - alert und Notfallquelle.
Unstimmigkeiten triangulation: 'fx (A→B) fx (B→C)' vs' fx (A→C)'- alert, loggen Sie die Diskrepanz in bps.

12) Beispiele für SQL-Vorlagen

12. 1. Normalisierung der Transaktionen in die Berichtswährung

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. Zersetzung des FX-Effekts der 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. Tägliche Neubewertung von Mehrwährungsrückständen (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) KPIs und Dashboards

FX Slippage (bps): Unterschied zwischen effective vs reference durch PSP/Methode/MID.
Realized FX P&L (Tag/Woche/Monat) und Unrealized FX (EoD/EoM).
Open FX Position auf Währungen vs Politik Grenzen.
Hedge Ratio: Anteil der gedeckten Position (vorwärts/NDF/Optionen).
Stale-rate Incidents и Triangulation Mismatch.
Spread% of Volume (wie viel FX im Verhältnis zum verarbeiteten Volumen gekostet hat).

14) Alerts und Schwellenwerte

Stale Preise: kein aktueller Kurs> N Minuten in der Spitze des Verkehrs - P1.
Spread spike: 'spread _ bps' über dem Schwellenwert für Dur/Moll - P2.
Offene Position breach: Überschreitung der Grenze für jede Währung - P1.
FX P&L Schock: Tag realized FX unter − X σ historisch - Untersuchung.
Crypto Preis Gap: Sprung> Y% des VWAP-Fensters - Umschalten der Quelle/Pause des Umschlags.

15) Best Practices (kurz)

1. Erkennen Sie ND und Produktmetriken zum settled-Kurs an, ohne retrospektive Neubewertung.
2. Speichern Sie für FI/Treasury den zweiten Kurs auf funded_at - Sie werden realized FX sehen.
3. Fixieren Sie immer conversion_owner, fx_source, quote_type und spread_bps.
4. Triangulation durch Anker (EUR/USD) mit Logging durchführen.
5. Trennen Sie realized und unrealized auf GL-Ebene.
6. Verwenden Sie in Crypto ein VWAP-Fenster, nicht ein einzelnes Tick.
7. Automatisieren Sie Alerts auf Stale-Raten und PSP-Spreads.
8. Prognostizieren Sie den Nettobedarf nach Währungen und verwenden Sie Natural Hedge + Forwards/NDF.

16) Checkliste Umsetzung

• Verzeichnis der Kurse' ref. fx_rates' mit EOD und Intraday, Quellspeicher und Quotentyp.
• Витрины `transactions_flat`, `fx_settlement_view`, `funding_receipts`.
• Triangulationsmechanik und Kursroutenprotokoll.
• Zweistufige FX-Buchführung (ND/Produkt vs FI/Treasury).
• Tägliche reval Mehrwährungsrückstände.
• KPI Dashboards (Slippage, Open Position, FX P&L).
• FX-Richtlinie: Positionslimits, White-List-Kontrahenten, Alert-Schwellenwerte.
• Hedging-Verfahren (vorwärts/NDF/Optionen) und Dokumentenmanagement.

Zusammenfassung

Bei FX bei iGaming geht es nicht nur darum, „den Kurs mit dem Betrag zu multiplizieren“. Es ist ein ganzes System: klare Anerkennungspunkte, transparente Kursquellen, Split Accounting Realized/Unrealized, PSP Spread Control und Managed Open Position. Durch die Implementierung eines Standard-FX-Handbuchs, einer Settle-Normalisierung, Reval-Verfahren und einer verständlichen FX-Politik mit Hedge-Instrumenten nehmen Sie die Volatilität aus dem P&L und machen die Cashflows vorhersehbar.