GH GambleHub

FX: conversión y riesgos cambiarios

1) Por qué administrar FX en iGaming

Informes P&L exactos: donde se produce una ganancia/pérdida FX (depósitos, retiros, PSP, reservas).
Justo ND/GRR/NGR: Una única currency reporting sin «revalorizaciones retroactivas».
Liquidez y cache flow: funding en moneda A, pagos en B - necesita pronóstico y cobertura.
Cumplimiento/impuestos: origen transparente de los cursos y auditoría de huellas.

2) Puntos clave donde nace FX

1. Billetera de juego vs moneda de depósito: normalización en la moneda monedero/reporting.
2. Capture/settle en PSP: se fija un curso «histórico» para ND.
3. Funding (inscripción en el banco): es posible un tipo de cambio/moneda diferente y un efecto FX secundario.
4. Withdrawals: conversión cuando se paga al jugador.
5. Reservas de rodillos y multas de esquemas: los cargos/lanzamientos pueden estar en otra moneda.
6. Crypto: evaluación de VWAP/mediana en el momento de settle/funding.

3) Fuentes de los cursos y normas de normalización

Fuente FX: prioritariamente proveedores de referencia (por ejemplo, CME/Refinitiv/ECB), en espera - banco/PSP.
Quote policy: `mid`, `bid/ask` или `mid ± spread_bps`. Para contabilizar es más común aplicar el mid + explícito 'spread _ bps'.
Timestamp: curso en el momento del evento de reconocimiento (normalmente 'settled _ at' para ND; opcionalmente 'funded _ at' para la cuenta bancaria).
No restatement: las ND pasadas no se sobreestiman cuando cambian de rumbo; reval se hace por separado como FX unrealizado.
Precisión: almacenar 8-10 caracteres en el curso FX, las cantidades de dinero - en minor units (integers) + scale.

4) Fórmulas y ejemplos

4. 1. Conversión básica

Deje que 'amount _ original' en 'ccy _ orig', la moneda de informe 'ccy _ amb', la tasa 'fx (ccy_orig→ccy_rep)':

amount_reporting = round(amount_original fx, scale_ccy_rep)

4. 2. Tipo de cambio cruzado (a través de moneda ancla, por ejemplo, EUR)


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

Es importante almacenar la ruta de los cursos (triangulación) en 'meta' para su auditoría.

4. 3. Separación del spread y la comisión PSP

Si PSP se ha convertido:

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

Almacene effective FX y reference FX para medir el margen PSP implícito.

4. 4. Ejemplo (cadena de doble conversión)

El jugador deposita 100 GBP. Reporting — EUR.
На `settled_at`: `GBP→EUR = 1. 1700` → `ND_dep = 117. 00 EUR`.
El PSP financia el banco en USD mañana: 'GBP→USD = 1. 3000 ', el banco mantiene una cuenta en USD.
Para la contabilidad FI, fije también el curso secundario 'USD→EUR' en 'funded _ at' (por ejemplo, 0. 9200) para ver FX realizado entre settle y funding si se revaloriza la posición monetaria.

5) DCC, conversión de PSP y «quién decide el rumbo»

DCC (Dinamic Currency Conversion) en el lado del merchant/PSP: el curso se muestra al jugador de antemano, pero el margen es mayor.
PSP-conversión: PSP acepta la moneda del jugador, convierte a la moneda del merchant a su tasa. La transparencia del spread es crítica.
Merchant-conversion: el merchant adopta multi-moneda (multi-MID/multi-cuenta), la conversión es realizada por el banco/trejery al mejor rumbo (generalmente más rentable, pero más difícil operativamente).
Recomendación: fijar el conversion_owner ('DCC', 'PSP', 'MERCHANT') y comparar el TCO (spread + fee).

6) Crypto: evaluación y volatilidad

Evaluación por VWAP por una ventana corta alrededor de 'settled _ at' (por ejemplo, ± 5 minutos), indicando la fuente (intercambio/proveedor).
Almacenar: 'price _ usd',' price _ eur ',' source ',' window ',' pair '(por ejemplo,' USDT/USDC/BTC ').
Para fundir en estables/fiat es la segunda capa de FX.
Especificidades: spikes, delistings, fees on-chain - tenga en cuenta en 'meta' y alertas.

7) Contabilidad de FX en los informes: realized vs unrealized

FX realizado es la diferencia «cerrada» por el flujo de efectivo (entre la tasa de reconocimiento y la tasa de cambio/ingreso real).
FX Unrealized: revalorización de los saldos de las cuentas/reservas de varias divisas al final del día/mes.
Divulgue a través de diferentes cuentas GL: 'FX _ realized', 'FX _ unrealized'.
Para análisis de productos/ND, utilice el curso histórico del evento (no sobrestime).

8) Tipos de exposición FX y cómo cerrarlos

Transaction exposure: no coincidencia de monedas de entrada/salida (depósito EUR → retiro TRY).

Medidas: hedge natural (recoger la moneda de pago), sobre rápido según las reglas.
Exposición de traducción: múltiples cuentas y reservas en diferentes monedas → EoD/EoM reval.
Exposición económica: dependencia a largo plazo del margen del curso (mezclas GEO, proveedores de juegos).

Medidas: forwards/NDF, options (collars), balance de GEO y proveedores.

9) Procesos y políticas de Trejery

Política FX: límites de posición abierta para cada moneda (por ejemplo, no más del 20% del volumen de negocios semanal).
Reglas de ejecución: volumen mínimo de la transacción, spreads de prague, lista de contrapartes.
Forecasting: 7/30/90 días de previsión de necesidades netas por moneda (depozity−vyvody−nalogi−ORYeKh).
Hedge accounting (si es necesario): documentar la relación «hedge position ↔ riesgo».
Calendario de vacaciones: afecta a la reserva de funding/rolling y al «cierre» de FX.

10) Datos y modelo (simplificado)


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) Verificación y control de calidad

11. 1. Alinear «nuestros» cursos con PSP/banco

Asigne 'fx _ effective' (de settlement) a 'fx _ reference' (de su referencia).
Alerta si '|spread_bps|> threshold' (por ejemplo,> 80 bps para mayores).

11. 2. Calidad de fuente de cursos

Stale-rates: si 'now - fx_timestamp> X minutos' al llegar el evento es una alerta y una fuente de emergencia.
Las inconsistencias de triangulación: 'fx (A→B) fx (B→C)' vs 'fx (A→C)' es una alerta, lógica la divergencia en bps.

12) Ejemplos de plantillas SQL

12. 1. Normalización de las transacciones en la moneda del informe

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. Descomposición del efecto FX PSP (referencia effectiva vs)

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. Revalorización diaria de las balanzas de divisas múltiples (FX unrealizado)

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

FX Slippage (bps): diferencia de referencia efectiva vs PSP/método/MID.
Realized FX P&L (día/semana/mes) y Unrealized FX (EoD/EoM).
Open FX Position por monedas vs límites de política.
Hedge Ratio: proporción de la posición cubierta (forwards/NDF/options).
Stale-rate Incidents и Triangulation Mismatch.
Spread% of Volume (cuánto costó FX con respecto al volumen procesado).

14) Alertas y umbrales

Stale rates: no hay un curso actual> N minutos en el pico del tráfico - P1.
Spread spike: 'spread _ bps' por encima del umbral para mayores/menores - P2.
Open position breach: superando el límite de cualquier moneda - P1.
FX P&L shock: día realizado FX abajo −Xσ histórico - investigación.
Crypto price gap: salto> Y% de la ventana VWAP - Cambiar la fuente/pausa del sobre.

15) Mejores prácticas (corto)

1. Reconozca las métricas de producto y ND en el curso settled, sin revaluaciones retrospectivas.
2. Para el FI/Trejery, guarde el segundo curso en el funded_at - vea el FX realizado.
3. Siempre fije conversion_owner, fx_source, quote_type, spread_bps.
4. Haga triangulación a través del ancla (EUR/USD) con lógica.
5. Comparta realized y unrealized a nivel GL.
6. En crypto - use una ventana VWAP, no un teca.
7. Automatice las alertas en stale rates y el spread PSP anormal.
8. Pronostique la necesidad neta por moneda y use hedge natural + delanteros/NDF.

16) Lista de verificación de implementación

  • Manual de cursos 'ref. fx_rates' con EOD e intraday, almacenamiento de origen y tipo quote.
  • Витрины `transactions_flat`, `fx_settlement_view`, `funding_receipts`.
  • La mecánica de triangulación y el registro del itinerario de los cursos.
  • Contabilidad FX de dos niveles (ND/producto vs FI/trejerie).
  • La reval diaria de los residuos de moneda múltiple.
  • Dashboards KPI (slippage, open position, FX P&L).
  • Política FX: límites de posiciones, contrapartes de lista blanca, umbrales de alertas.
  • Procedimiento de hedging (forwards/NDF/options) y procesamiento de documentos.

Resumen

FX en iGaming no es sólo un «curso multiplicado por la cantidad». Se trata de todo un sistema: puntos de reconocimiento claros, fuentes de cursos transparentes, contabilidad dividida realizada/unrealizada, control de spread PSP y posición abierta gestionada. Al implementar la referencia FX estándar, la normalización «por settle», los procedimientos reval y una política FX comprensible con herramientas de cobertura, elimina la volatilidad de P&L y hace que los flujos de efectivo sean predecibles.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.